Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice
  2. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  3. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Suggestion on relative execution order decorator

Discussion in 'Experimental Scripting Previews' started by Jelvand, Jul 16, 2021.

  1. Jelvand

    Jelvand

    Joined:
    Oct 4, 2019
    Posts:
    4
    Hi,
    We are in some cases using unity together with real-time hardware sensors and similar, and are sometimes running into execution order issues due to this. This is further complicated by some of the libraries for the C#/unity integration residing in pre-compiled managed dlls that are included in the projects.
    Due to this way of integrating, together with some decoupling design decisions, there may for example be a monobehavior in the dll with no explicit execution order, that takes an interface generalizing the specialized hardware access, that needs to be implemented concretely. This concrete class in turn may be reliant on 3'd party unity code for the hardware, which is further relying on native driver execution. So what we have is basically a chain of monobehaviors that are dependent on each other's initialization despite decoupling etc.

    What we have run into is that the Awake() and Start() functions are not always enough to create the step-by-step execution dependency, and we don't always have the choice of re-designing 3'd party, or implementations residing in pre-compiled DLLs, to only have self-initialization in Awake, and other mechanisms to avoid time dependency like start-up time for the hardware.

    So we need to do tweaking either with [DefaultExecutionOrder(int)] or remember to carefully craft the list in project settings for script execution order.
    This is fine as a solution, although what we could really use is a more relative specification of execution order to make things easier and not have to bother with what number we have put on execution order, especially since the class may be reused elsewhere and need another number there.

    What I would like to propose is another decorator allowing for relative execution order instead of explicit.
    E.g. something like this
    [ExecuteAfter(typeof(A))]
    class B: Monobehaviour
    {...}
    I assume the decorator would also allow for compile time detection of circular dependency (like A saying it should execute after B, and B saying it should execute after A).

    Is it just us, or does anyone else think this might be a good idea?