Evaluation order of logical operators

[DuartePina]

I wanted to know what is the order in which nools parses logical operators in the rules.
When I was testing some rules detection using a Class I've made to be used inside the scope to validate some conditions, i've noticed that the DSL was parsing them bottom-up.
Is it possible to confirm if this is intended to work this way?

example (doesn't work):

rule "some_name" {
  when {
    e : DefinedObject
      e.attrib1 == "something1" &&  
      e.attrib2 == "something2" &&
      MyClass().getObject(e.id).match("some_info") &&
      MyClass().selectedObject().getChild().match("other_info");
  }
}

In this exemple, i want to get and save a object with the e.id and match it to some information, after that i want to get the selected objects' child and match to another info.
Nools then gives a error saying that "selectedObject" is not defined, however when I change the order it works fine.
I wanted nools to confirm MyClass functions after it validates the e.attributes but for this, they must also be written after

example (does work):

rule "some_name" {
  when {
    e : DefinedObject
      MyClass().selectedObject().getChild().match("other_info") &&
      MyClass().getObject(e.id).match("some_info") &&
      e.attrib2 == "something2" &&      
      e.attrib1 == "something1";

  }
}

Is it working with some kind of stack, FILO? Could you shed some light into it please?

Thank you

[DevSide]

I would say there is no specific evaluation sequence. Conditions are evaluated over time while the engine is running. selectedObject should probably be a fact ?

[DuartePina]

The selectedObject was to store 1 element from a long tree of objects in order to not iterate it in every fact, created by the getObject(e.id), and match/compare some of its attributes.
Due to the lack of response (its been over a year since the issue was created), and since it worked as expected using the 2nd example, I kept it like that. Although the project has now changed course and left this coast.
As of now, I think its some food for thoughts if any1 has a similar issue.

[DevSide]

Your constraint MyClass().selectedObject().getChild().match("other_info") doesn't look to depend on your fact DefinedObject . It will be always re-evaluted. You really prefer using more facts than dynamic expressions to get a better flow.
I will figure out though, what's really happening in the engine with this kind of evaluations.

[DuartePina]

Please note that somethings I wont be able to recall as it was a long time ago, but I'll try to as best I can.

The constraint do depend on the fact DefinedObject.
If you look at the fact before my MyClass().selectedObject() (using the 1st example), I call a MyClass().getObject(e.id) with e beeing my DefinedObject, saving the reference to the object that matched that e.

The rules were to spot unwanted changes in our Tree and classify them accordingly. The MyClass().selectedObject().someMethod(someString) would allow to do multiple logical facts (like matching parents or child nodes) with no extra resources beeing funneled into a Tree search.

Some more info I can give about the original post is that I only wanted to do the MyClass().getObject(e.id) after and only after the e.attrib2 == "something2" && e.attrib1 == "something1"; return true.