EvaluateVariable delegate intended operation?

[lholbert]

Say I have an object, OBJ, which has a property Property.
I also setup an EvaluateVariable() delegate.
In my variable dictionary, I have the entry ("OBJ", OBJ)

I ask the engine to evaluate:
OBJ.Property

In regards to OBJ, the EvaluateVariable() delegate is only called if the OBJ entry is not included in the dictionary.

However, in regards to Property, EvaluateVariable() is called every time.

• If EvaluateVariable() simply returns on this call (and doesn't set e.Value), the engine will use the value returned by OBJ.Property
• If EvaluateVariable() does set e.Value, the engine will use that value

Is this the intended behavior? It seems inconsistent. I expected EvaluateVariable() would only get called for Property, if the Property was not part of OBJ proper.

VS2019, NuGet version 1.3.7

[codingseb]

Yes it's the intended behavior.
I personally use it to modify the behavior of some object when used with ExpressionEvaluator.
But I understand your concern. I could add an option to define the priority between existing Properties/fields/methods and EvaluateVariable and EvaluateFunction events.
What do you think ?

[lholbert]

It's your baby Seb, but yes, I would agree with that as an option.

Thank you for the quick response and considering optional functionality.

[codingseb]

In fact for this one, I think I have better idea.
I will add 2 more events that will be fired before evaluation with the possibility to cancel the evaluation of the variable or function. The 2 current events will be evaluate in a second time if no existing variables or functions are found.

Just be aware that using events after all other evaluations will be slower.

[lholbert]

Sorry didn't see this response.

I think it might have been the actual root of my question, to begin with. Why the variable function was getting called for the property if it did exist (which you answered) ... which was adding some performance overhead that wasn't needed. The proposed solution will essentially be the same overhead as there is now, just reskinned (still that function call to cancel the lookup).

In my mind, the default condition (i.e. the property already exists), should be the quickest path of execution, with no additional overhead needed.

I've looked at several of these libraries, love yours, and will stick with it. Whatever you choose is fine by me. Thanks for your responses!

[codingseb]

In the begining of ExpressionEvaluator these events were evaluate after all. At some point I changed it to improve the perfs and to redefine some stuff on the fly. The doc about "on the fly" event was written with event evaluated after and I did'nt rewrite it. So it can be confusing.
I think to have the 2 solutions available can be good. I will of course update the doc on the wiki to explain the difference between evaluating before and after.

I think the "after" evaluation can be useful if you don't want to think about eventually conflicts with existing variables and properties. The drawback about perfs just need to be documented.

I will also publish a "breaking change" version to inform of the change so next version will be 1.4.0.0

Thanks for your words. I am happy if this library is useful.

[codingseb]

OK version 1.4.0.0 resolve this issue. See this for more infos