Well, it looks like I was wrong. I just tested the following in Flash, and then both give the same results (i.e. return the attribute):
var emp = e.employee.(@id == 1).@name; // name of employee with id 1 var foo = e.employee.(1 == @id).@name; // name of employee with id 1 > On Aug 7, 2018, at 10:27 AM, Harbs <harbs.li...@gmail.com> wrote: > > Your example does not seem to be right to me. > > Here’s the overview of how filters are supposed to work from the spec: > >> Overview >> When the left operand evaluates to an XML object, the filtering predicate >> adds the left operand to the front of the scope chain of the current >> execution context, evaluates the Expression with the augmented scope chain, >> converts the result to a Boolean value, then restores the scope chain. If >> the result is true, the filtering predicate returns an XMLList containing >> the left operand. Otherwise it returns an empty XMLList. >> When the left operand is an XMLList, the filtering predicate is applied to >> each XML object in the XMLList in order using the XML object as the left >> operand and the Expression as the right operand. It concatenates the results >> and returns them as a single XMLList containing all the XML properties for >> which the result was true. For example, >> >> var john = e.employee.(name == "John"); // employees with name John >> var twoemployees = e.employee.(@id == 0 || @id == 1); // employees with id's >> 0 & 1 >> var emp = e.employee.(@id == 1).name; // name of employee with id 1 >> >> The effect of the filtering predicate is similar to SQL’s WHERE clause or >> XPath’s filtering predicates. >> For example, the statement: >> >> // get the two employees with ids 0 and 1 using a predicate >> var twoEmployees = e..employee.(@id == 0 || @id == 1); >> >> produces the same result as the following set of statements: >> // get the two employees with the ids 0 and 1 using a for loop >> var i = 0; >> var twoEmployees = new XMLList(); >> for each (var p in e..employee) { >> with (p) { >> if (@id == 0 || @id == 1) { >> twoEmployees[i++] = p; >> } >> } >> } > > The question is what is "the front of the scope chain of the current > execution context”? I’m pretty sure that means the start of sub-expressions. > I don’t see how that can apply to the right-hand of comparison expressions. > There is nothing in the spec about figuring out if a part of an expression is > referring to XML or XMLList. > >> On Aug 7, 2018, at 9:45 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: >> >> I don't get what portion of the spec has to do with whether we append "node" >> to various expressions. IMO, the changes I made only affect 6b. 6a is >> handled by generating a function with "node" as the parameter (because node >> is list[i] in the spec). The task in 6b is to correctly evaluate any e4x >> filter expression. I'm not sure what the limits are on what you can have in >> a filter expression, but if you can have just plain "@app" anywhere in the >> filter expression, I don't believe scoping rules would know to apply that to >> the "node" parameter without generating the "node" before "@app". >> >> There is a chance that the Flex Compiler was using "magic" to generate the >> "node" and really should have reported an error. I do remember being told >> that the filter function can be "anything". Even: >> (var foo:int = @app.length(); foo > @bar.length()) >> >> If there are actual rules in the spec about evaluating the expression, that >> might apply to how we handle these expressions, otherwise I think the right >> thing is to resolve each expression and if the expression does not resolve >> to anything else, assume that it applies to the node. I know the logic in >> EmitterUtils.writeE4xFilterNode isn't covering all cases. It is trying to >> see what the expression resolves to, and returns false for known conditions >> (like a member of a class). Just make it return false for your case (and >> feel free to add that case to the tests). Eventually we'll have enough >> cases to either call it "good enough" or figure out a better way to >> determine when the expression applies to "node". >> >> My 2 cents, >> -Alex >> >> On 8/6/18, 11:20 PM, "Harbs" <harbs.li...@gmail.com> wrote: >> >> I just looked at the spec. I think it’s correct to append “node” to the >> first statement of the expression only. The only exception seems to be >> expressions which use boolean expressions (i.e. || or &&) in which case each >> piece of the boolean expression should be considered a self-contained >> expression. So in your example, there are really two filter expressions: >> 1. hasOwnProperty("@app”) >> 2. @app.length() > 0 >> >> Both of those should have node appended to the front, but nothing else. >> >> Here’s the relevant semantics in the spec (the important bit being 6a): >> >>> 6. For i = 0 to list.[[Length]]-1 >>> a. Add list[i] to the front of the scope chain >>> b. Let ref be the result of evaluating Expression using the augmented scope >>> chain of step 6a >>> c. Let match = ToBoolean(GetValue(ref)) >>> d. Remove list[i] from the front of the scope chain >>> e. If (match == true), call the [[Append]] method of r with argument list[i] >>> 7. Return r >> >> Makes sense? >> >> Harbs >> >>> On Aug 7, 2018, at 1:39 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: >>> >>> In porting Tour De Flex, there were patterns like this (explorerTree is >>> XML): >>> >>> explorerTree..node.(hasOwnProperty("@app") && @app.length() > 0) >>> >>> The compiler logic before I made any changes yesterday just assumed that >>> the first expression was a reference to the node parameter but other >>> expressions were not, but it looks like the expression "@app.length()" was >>> allowed in Flex as a reference to the node. So I think the compiler has to >>> determine what expressions evaluate to "nothing" which implies they are >>> references to the node, and what did resolve to something. This is all new >>> logic and I don't know how to determine all of the test cases up front, so >>> we'll have to keep tuning it as we find patterns that don't work as we want >>> them to. >>> >>> In your case, if the expression resolves to a VariableDefinition, that >>> probably means that isn't a reference to node. Not exactly sure, so you >>> should debug into it to see what the node pattern is and return false. >>> >>> Thanks, >>> -Alex >>> >>> On 8/6/18, 3:28 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>> >>> Doesn’t it always need to be a method for it to reference the node? >>> >>> I.e. child() should be node.child(), but foo.baz would not. >>> >>>> On Aug 7, 2018, at 1:12 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: >>>> >>>> Yep, we need more intelligent understanding of when a reference is to the >>>> node or not. >>>> >>>> Debug into EmitterUtils.writeE4xFilterNode and figure out the node pattern >>>> you need. >>>> >>>> -Alex >>>> >>>> On 8/6/18, 3:09 PM, "Harbs" <harbs.li...@gmail.com> wrote: >>>> >>>> var folderFolders:XMLList = >>>> assetXML.folder.(child('key').indexOf(folder.key) == 0); >>>> var folderImages:XMLList = >>>> assetXML.image.(child('key').indexOf(folder.key) == 0); >>>> >>>> Is now compiled as: >>>> >>>> var /** @type {XMLList} */ folderFolders = >>>> this.assetXML.child('folder').filter(function(node){return >>>> (node.child('key').indexOf(node.folder.key) == 0)}); >>>> var /** @type {XMLList} */ folderImages = >>>> this.assetXML.child('image').filter(function(node){return >>>> (node.child('key').indexOf(node.folder.key) == 0)}); >>>> >>>> “node.folder.key” is not correct. “folder” is a local variable of an un >>>> related object type. >>>> >>>> I assume this broke with the recent XML filter changes. >>>> >>>> Harbs >>>> >>> >>> >>> >> >> >> >