Re:Basic Concepts in Unity for Software Engineers
by jayd16 on Monday October 12, 2020 @05:21PM
(#24759572)
You've just shifted the problem. Its better to just track your exact state and leverage the fact that you get exclusive atomic control of the main thread until you yield or return.
The only lifecycle a behavior can trust is its own. Relying on other objects turns into a mess when your weak assumptions are violated.
Besides causing a spaghetti mess of lifecycle tracking and callbacks and such, it leaves you wide open to the major problem if callbacks running pass the life of the thing to call back to. You've thrown away Unity's lifecycle tools by dumping everything into a big pot. Now you have to null-check in the callbacks to make sure your things are still alive. Track your own state and you'll be fine.
Coroutines will stop when the owner dies and that is by design. Leverage that to ensure brain dead clean up.
Objects are very often going to be disabled through user action anyway, eg quitting a level. Its better to just assume that will happen at any time and plan accordingly.
The only lifecycle a behavior can trust is its own. Relying on other objects turns into a mess when your weak assumptions are violated.
Besides causing a spaghetti mess of lifecycle tracking and callbacks and such, it leaves you wide open to the major problem if callbacks running pass the life of the thing to call back to. You've thrown away Unity's lifecycle tools by dumping everything into a big pot. Now you have to null-check in the callbacks to make sure your things are still alive. Track your own state and you'll be fine.
Coroutines will stop when the owner dies and that is by design. Leverage that to ensure brain dead clean up.
Objects are very often going to be disabled through user action anyway, eg quitting a level. Its better to just assume that will happen at any time and plan accordingly.