Romek
Super Moderator
- Reaction score
- 963
ThanksIn any case, yeah, I guess a large merit of this system is the friendly, intuitive syntax it implements (just like the unit group vs unit array interface), which could be useful in a situation where large numbers of large arrays would be managed as the alternative.
@ Romek/Flare
That should error - that's not how .execute() is used. .execute() and .evaluate() are used on function interfaces.
Maybe you'd want to switch to using function interfaces, Romek? Then you could make the trigger Enum function take arguments and remove the need for GetEnumTrigger() calls. It would all be less error-prone (no ExecuteFunc() crashes) and more friendly, not requiring users to use those scope prefixes.
The code argument has already been implemented
UnitGroups have this problem too.Requiring users to call this function seems like a bit of a regression, especially in a system that's supposed to automate things. Destroying dynamic triggers is bad practice anyway. Maybe the check could be omitted (unneeded), or done periodically?Code:function RefreshTriggerGroup takes triggergroup tg returns nothing
Also, refreshing automatically gives the user less control over the system
Finally, why not make the extension code part of the system? Packaging it all together doesn't seem like a bad idea.
Well, I split them up because the 'extension' could be easily made using the main system. Those are just the most common tasks.