boolexpr instances

[sethmachine]

Hi,

I am a bit confused on how JASS treats boolexpr instances. From my understanding of OOP from Java and Python, an object instance is unique when it is created, i.e. it is allocated its own memory.

Thus for example these two objects should not be equal, since while they have the same values for fields, they have different memory locations.

location A = Location(0,0)
location B = Location(0,0)

//this should return false
if A == B then
  call print("I'm wrong!")
endif

//location B should not be null
call RemoveLocation(A)

if B != null then
  call print("I'm right!")
endif

Assuming this is the correct behavior for objects in JASS, I do not understand this behavior from this point of view.

boolexpr A = Condition(function main)
boolexpr B = Condition(function main)

//from my understanding, A and B should be unique instances
//but that's not really true apparently.  

call DestroyBoolExpr(A)
//now B won't work anymore!

If I sketched the behaviors wrong, please correct me. I understand it doesn't really make much logical sense to have unique instances of boolexpr since its just a callback to an immutable function.

So what happens when we create a new boolexpr instance which has already be made? Does JASS simply tell it to point to the oldest one, e.g.

boolexpr A = Condition(function main)
//this is equivalent to: boolexpr B = Condition(function main)
set B = A

What other instances behave this way?

 

[WaterKnight]

Yes, boolexprs are recycled. But instances of them created by

native And takes boolexpr operandA, boolexpr operandB returns boolexpr
native Or  takes boolexpr operandA, boolexpr operandB returns boolexpr
native Not takes boolexpr operand returns boolexpr

are unique. Filter() does the same as Condition(), conditionfunc and filterfunc are actually the same.

The only other type where you can find such behavior, I have in mind, is texttag, when you have 100 texttags, it overwrites the 0, which is weird anyway because it's basically null, as if it returns an invalid value.

 

[sethmachine]

Ah I actually did not know we could create new boolexpr dynamically via the logical operators. But the same rules would apply, e.g.

boolexpr A = Condition(function main1)
boolexpr B = Condition(function main1)
boolexpr C = Condition(function main2)
boolexpr D = Condition(function main2)

//are these the same, AC and BD?
boolexpr AC = And(A, C)
boolexpr BD = And(B, D)

//are these same, AC and CA?
boolexpr AC = And(A, C)
boolexpr CA = And(C, A)

 

[WaterKnight]

Those are not the same. Caching concatenations of arbitrary depth would be rather complex and often boolexprs created this way are more dynamic and you should destroy them (or recycle them yourself). Actually, the only situation where And() is used to my knowledge (apart from GUI), is for pick functions -> http://www.wc3c.net/showthread.php?t=104464.

 

[sethmachine]

Ah right so once we start making dynamic boolexprs, they are always unique and behave like other objects. WC3 isn't smart enough to know that in the example I gave AC, BD have the same truth values. Likewise for AC, CA.

 

[WaterKnight]

You can nest Ands, Ors, Nots.

Not(And(And(Or(A, B), C), Or(D, E)))

In this case, the parameters become virtual (the boolexprs are not statically available as a single function). So even if everything was recycled, you can potentially dynamically leak.

 

[sethmachine]

In your example

Not(And(And(Or(A, B), C), Or(D, E)))

There would be 4 leaks, not counting the final NOT operator? When I say leaks I mean memory that won't ever be returned, e.g. Or(D,E) is definitely a leak, unless we cached it to a variable before hand?