Detect Ressource Exchange System

1234

You pollute the global textmacro name table with the inaptly named "Macro". You declare variables outside of the macro that should be inside the macro. I do believe scope initializers work when nested in libraries, so you have no excuse for not using a scope with an initializer in the macro.

You use the type conditionfunc instead of boolexpr. While Filter() and Condition() return subtypes of boolexpr, all functions take values of type boolexpr. Using the subtypes is just unnecessary and confusing, adding needlessly to code complexity. The subtypes act the same, so use the parent type.

Register$TYPE$Exchange breaks with the convention of trigger event registration functions starting with "TriggerRegister".

Your whole system breaks JASS convention by specifying a pair of function sets, instead of a single function set which take a constant.

Your Get functions to get the value of things inside the trigger are not thread-safe. Attach data to the trigger and retrieve it on Get call to make them thread-safe. (GetTriggeringTrigger() is your friend.)

You provide two internal implementations. For a system this simple, that's bad. Pick the best way, and stick to it.

I'm too lazy to examine the actual logic and functionality of this, but I think my current gripes are enough for now.

Originally Posted by Earth-Fury

You pollute the global textmacro name table with the inaptly named "Macro".

Who care really ? This part of the code should not be edited.

Originally Posted by Earth-Fury

You declare variables outside of the macro that should be inside the macro. I do believe scope initializers work when nested in libraries, so you have no excuse for not using a scope with an initializer in the macro.

Ok i will edit that. I though it was just more readable.

Originally Posted by Earth-Fury

You use the type conditionfunc instead of boolexpr. While Filter() and Condition() return subtypes of boolexpr, all functions take values of type boolexpr. Using the subtypes is just unnecessary and confusing, adding needlessly to code complexity. The subtypes act the same, so use the parent type.

Ok.

Originally Posted by Earth-Fury

Register$TYPE$Exchange breaks with the convention of trigger event registration functions starting with "TriggerRegister".

I though it was annoying long, or not ?

Originally Posted by Earth-Fury

Your whole system breaks JASS convention by specifying a pair of function sets, instead of a single function set which take a constant.

You want mean something like that ?
TriggerRegisterResourceExchange(<yourTrigger>,<yourForce>, <an integer constant names like GOLD, LUMBER>)

Originally Posted by Earth-Fury

Your Get functions to get the value of things inside the trigger are not thread-safe. Attach data to the trigger and retrieve it on Get call to make them thread-safe. (GetTriggeringTrigger() is your friend.)

But what happens if a trigger is destroyed ?
I know that's a bad thing and we should recycle them.
But is there a safe method to "store" triggers and manage the leaks if the user create and destroy triggers during the game ?

Originally Posted by Earth-Fury

You provide two internal implementations. For a system this simple, that's bad. Pick the best way, and stick to it.

True i will make only one.

Originally Posted by Earth-Fury

I'm too lazy to examine the actual logic and functionality of this, but I think my current gripes are enough for now.

Enough, that's the word :p

Originally Posted by Troll-Brain

Who care really ? This part of the code should not be edited.

When someone else creates a system that uses a textmacro named "Macro", you will see the problem...

Originally Posted by Troll-Brain

I though it was annoying long, or not ?

If you're going to make a system that follows the convention of using triggers, instead of using Function Interfaces (Which really, kick ass.), you should follow convention.

Originally Posted by Troll-Brain

You want mean something like that ?
TriggerRegisterResourceExchange(<yourTrigger>,<yourForce>, <an integer constant names like GOLD, LUMBER>)

Yes.

Originally Posted by Troll-Brain

But what happens if a trigger is destroyed ?
I know that's a bad thing and we should recycle them.
But is there a safe method to "store" triggers and manage the leaks if the user create and destroy triggers during the game ?

Use a storage system that doesn't need to be cleaned. Arrays, after allocated, will not ever take up less space again. Considering you only need to store native values, and not pointers on the trigger, you also don't have to worry about deallocation of handles. Something like DataSystem should do:
credit to grim001 - Wc3campaigns

Originally Posted by Earth-Fury

When someone else creates a system that uses a textmacro named "Macro", you will see the problem...

Have you seen that i add "once" to the macro ?
Anyway i will change the name.

Originally Posted by Earth-Fury

If you're going to make a system that follows the convention of using triggers, instead of using Function Interfaces (Which really, kick ass.), you should follow convention.

What did you mean. I should use function interfaces instead or not ?

Originally Posted by Troll-Brain

Have you seen that i add "once" to the macro ?
Anyway i will change the name.

JassHelper 0.9.9.9

The library_once keyword works exactly like library but you can declare the same library name twice, it would just ignore the second declaration and avoid to add its contents instead of showing a syntax error, it is useful in combination with textmacros.

Hint: You can use textmacro_once in a similar way to library_once.

According to the documentation, //! textmacro_once simply causes any additional declarations to be completely ignored instead of throwing a syntax error (which SHOULD occur in this case, considering your macro _needs_ to execute properly for the library to work.)

Originally Posted by Troll-Brain

What did you mean. I should use function interfaces instead or not ?

Completely up to you. The trigger event design pattern is perfectly valid. I just really like the simplicity function interfaces can give to a lot of things.

As the library DataSystem, i update my system as well.

It seems that' a "nice" (i can't be objective) useless system.

Do you want a replay which prove it works as intended ?