[vJASS] Condition vs Filter!!

[Kazeon]

Condition(function ...) VS Filter(function ...)

???

 

[edo494]

one returns conditionfunc, the second returns filterfunc. They were meant to be used: Condition for trigger's conditions and Filter was meant to be used where you want to filter stuff(enumerations).

They, not the same type, implicitly convert to boolexpr, and apparently even TriggerAddCondition is fine with plain boolexpr

 

[Kazeon]

But both works correctly for both TriggerAddCondition and ForGroup :/

 

[edo494]

My rough guess is that the compiler doesnt actually check whether the type you pass in is conditionfunc or filterfunc, but can take any boolexpr. And the interpreter doest seem to give shit about what it eats anyways(Typecasting anyone?)

 

[PurgeandFire]

It doesn't matter which you use.

In general, it is a good habit to use Condition() for trigger conditions and Filter() for groups.

The reason why you can use either one is because the natives are defined to take in a boolexpr:

native TriggerAddCondition    takes trigger whichTrigger, boolexpr condition returns triggercondition
native GroupEnumUnitsOfPlayer               takes group whichGroup, player whichPlayer, boolexpr filter returns nothing
native ForceEnumPlayers         takes force whichForce, boolexpr filter returns nothing
// etc ..

The hierarchy is:

Condition() returns conditionfunc extends boolexpr
Filter() returns filterfunc extends boolexpr

When you have this hierarchy, you can use any of the child representations to input into the base type. Consider boolexpr the parent, and filterfunc/conditionfunc as the child types.

If a function asks for a boolexpr, you can input either a filterfunc or conditionfunc (children).
If a function asks specifically for a conditionfunc, you can input a conditionfunc but not an arbitrary boolexpr or a filterfunc.
If a function asks specifically for a filterfunc, you can input a filterfunc but not an arbitrary boolexpr or a conditionfunc.

I haven't tested it though. The first rule is true (hence, why this thread was made). The second and third can be confirmed if these throw errors:

function A takes nothing returns boolean
    return false
endfunction

function B takes nothing returns nothing
    call DestroyCondition(Filter(function A)) // should throw an error
    call DestroyFilter(Condition(function A)) // should throw an error
endfunction

If it doesn't, welp then that means the interpreter is inconsistent. An easier example can be seen with the widget hierarchy. The widget type is a parent to the child types unit, destructable, and item. When asked to input a widget, you can use any of those child types. When asked to input a unit specifically (for example), you can't input any arbitrary widget. It has to be specifically a unit (and typecasting can help with that).

-----
TL;DR Is there a difference between the two functions? Yes. One is named "Condition" and the other is called "Filter". But there is no practical difference. Use them as you like, but I recommend using Condition for conditions and Filter for group filters.

The point of this post was to clarify how the compiler works.