Nestharus
o-o
- Reaction score
- 84
onDestroy needs to be called inside of a trigger evaluation.
There is a reason why it is done that way in vJASS.
edit
Notice that with your current design, onDestroy in Guard would not be called if UnitGuard was destroyed. This is the reason why there need to be trigger evaluations. Each instance would get a trigger and as the things are created, the onDestroy things would be piled on to that trigger. When destroy is called at any of the instances, the trigger is evaluated, meaning that all of the stuff gets properly destroyed.
If you are supporting onDestroy, you need to do that because that is what it traditionally does in vJASS.
People would be doing inheritance via delegates, meaning that you end up registering and doing all sorts of other nonsense.
I suggest just taking onDestroy out and leaving it up to the user to call it however they wish.
There is a reason why it is done that way in vJASS.
edit
JASS:
struct Guard
static method create takes nothing returns thistype
set guard = CreateUnit(...)
return this
endmethod
method onDestroy takes nothing returns nothing
call RemoveUnit(guard)
set guard = null
endmethod
endstruct
struct UnitGuard extends Guard
static method create takes nothing returns thistype
call AddSomeCoolEffect(guard)
endmethod
Notice that with your current design, onDestroy in Guard would not be called if UnitGuard was destroyed. This is the reason why there need to be trigger evaluations. Each instance would get a trigger and as the things are created, the onDestroy things would be piled on to that trigger. When destroy is called at any of the instances, the trigger is evaluated, meaning that all of the stuff gets properly destroyed.
If you are supporting onDestroy, you need to do that because that is what it traditionally does in vJASS.
People would be doing inheritance via delegates, meaning that you end up registering and doing all sorts of other nonsense.
I suggest just taking onDestroy out and leaving it up to the user to call it however they wish.