Invoke method of instance events in a Singleton becomes no longer callable in static context.

[chris24xd]

Assume we have this simple singleton.

using UnityEngine;

public class ExampleSingleton : MonoBehaviour
{
    public static ExampleSingleton Instance {get; private set;}
    public event Action ExampleEvent;
    
    private void Awake() => Instance = this;
    public static void InvokeExampleEvent() => Instance.ExampleEvent?.Invoke();
}

When adding the [Singleton] attribute to the class and doing the appropriate changes, the Invoke method for ExampleEvent is no longer callable, because now Instance is an interface instead of an instance class.

using UnityEngine;
using EngineRoom.Runtime.Singleton;

[Singleton]
public class ExampleSingleton : MonoBehaviour
{
    public event Action ExampleEvent;
    
    public static void InvokeExampleEvent() => Instance.ExampleEvent?.Invoke(); // No longer possible!
}

This is only solveable if you change the method to a non-static one, making ExampleEvent directly accessible in its own class. What if you really wanted to keep code simpler and use a static method for this purpose?

[migus88]

Hey @chris24xd, sorry for the late reply - this one slipped past me!

So this is actually by design rather than a limitation. The whole point of the package is to get rid of global static access to singletons - that's why Instance is typed as the generated interface instead of the concrete class. A public static void InvokeExampleEvent() would let any code anywhere fire the singleton's event, which is exactly the kind of hidden coupling the interface is there to prevent.

There's another reason too: by keeping all access behind an interface, your code never depends on the singleton pattern itself. If you later decide to move to a service locator or proper DI, you swap out how IExampleSingleton gets resolved - the consuming code doesn't change. Static methods and static event invokers would lock you into the singleton forever, and that's the trap this package is trying to keep you out of.

The migration path is to make the invoker an instance method, so it becomes part of the singleton's contract:

[Singleton]
public partial class ExampleSingleton : MonoBehaviour
{
    public event Action ExampleEvent;

    public void NotifyExampleThing() => ExampleEvent?.Invoke();  // exposed on IExampleSingleton
}

• If the singleton itself decides when the event fires, just raise it from its own instance methods - no Instance needed at all.
• If other code needs to trigger it, call NotifyExampleThing() through the interface - ideally via [Dependency] private IExampleSingleton _example;. Keeps everything interface-typed and mockable in tests, which a static invoker can't be.

So yeah - the extra keystroke is deliberate. Raising an event stays the class's privilege, everything else goes through the interface.

I will close the issue later as by-design, but happy to keep discussing if you've got a case this doesn't cover!