Thanks for checking that. child is specified in 13.4.4.6 and essentially calls [[Get]] (After cycling through this kind of thing a few times, I found the easiest way to find methods is to search in the spec for 'e.mehodName' which gets you XML.prototype.methodName)
and [[Get]] is specified in 9.1.1.1 So I assume it is a bug. As discussed I think it is good to match the behavior. If we can verify 100% it is off spec, we could add something as a define to avoid the 'fix' for people who want to be on-spec. On Sat, Sep 7, 2019 at 11:30 AM Alex Harui <[email protected]> wrote: > FWIW, I went and looked at the ABC. > > The first syntax sets up a getProperty just like any other property > fetch. The second (as expected) calls "child()". I've looked at the E4X > spec a couple of times now and cannot see where the behavior we are seeing > in child() is specified so I am going to assume it is a bug, and that we > just have to live with it. > > I expect that getProperty does not call child(). I haven't looked at the > AVM code to see what getProperty does for XML. > > HTH, > -Alex > > On 9/5/19, 12:05 PM, "Greg Dove" <[email protected]> wrote: > > Oh that is a good find! And perfect timing :) > Thanks Alex, I am pretty sure that answers the question! (It quite > specifically describes what I was seeing, I don't think it makes a > difference whether it is attributes or elements) > > And yes, I agree it should be the implemented to give the same results > as > swf. > I will add this to the other work I have over the weekend before I get > it > in. It only seems relevant for when child (or descendants, I don't > expect > that will be different) method call is explicit (as opposed to the > compiler-generated method calls from e4x 'member access') with QName > argument only. I think most people won't use this approach with > explicit > QNames, but it is one of those things that will cause misery if you do > (when porting legacy code), so it should be the same IMO also. I will > make > sure it costs nothing for the more common (other) use cases. I have > had to > do something similar to support 'use namespace' directives which > create a > MultiName-like variant of QName in my local change that includes the > default namespace and the specified set of other 'used'/open namespace > uris > in the current execution scope. (That 'use namespace' pattern was being > used quite a bit in the codebase I have been working on) > > Thanks again, that will save me investigating it with bytecode. > > > > > On Fri, Sep 6, 2019 at 6:37 AM Alex Harui <[email protected]> > wrote: > > > Out of pure random chance, I was starting the migration of WebService > > which had a dependency on XMLUtil which contained the comment: > > > > //xml.attribute(QName) will also return local no-namespace > > attributes > > //even if we are looking for a specific full qualified name. > > > > So, still could be a bug in Flash, but maybe we should just make our > > implementation work the same way to reduce migration effort in case > someone > > is relying on this behavior. > > > > Thoughts? > > -Alex > > > > On 9/4/19, 1:47 PM, "Alex Harui" <[email protected]> wrote: > > > > I read the example incorrectly. So yeah, it should return 0 and > empty > > string in both cases, IMO. There might be some subtlety in how the > > namespaces are specified for a QName or how QName works in child(). > > > > HTH, > > -Alex > > > > On 9/4/19, 11:33 AM, "Greg Dove" <[email protected]> wrote: > > > > Good idea. I'll check the swf output, although probably > tomorrow > > as I need > > to focus on something else today. > > ' I would have expected both to return "1" and the node. ' > > > > In that example I would expect the opposite (because the the > link > > node > > being returned by the second query is not in the specified > explicit > > namespace of the QName), so I am curious to understand why > you > > think > > that... maybe it will help me understand. > > > > When I use feed.atom::link I expect only links that are > bound to > > the atom > > namespace (uri). Because <link ... /> node has no prefix > bound to > > the uri > > that the atom namespace defines, and it is in the default > > namespace, I > > would not expect it to be included. > > At the moment the atom::link part is working the same as > swf, so > > I'm happy > > with that at least for what I am working on. All the explicit > > calls to > > child(name) or descendants(name) in the app I am working on > use > > string args > > so these all work correctly as well. > > I'm just trying to cover things for the future... while my > head is > > still in > > this stuff. > > > > > > > > On Thu, Sep 5, 2019 at 6:11 AM Alex Harui > <[email protected]> > > wrote: > > > > > Speaking of multinames, what is the ABC code generated by > the > > Flex > > > compiler for the two cases? It might contain some clues. > I > > would have > > > expected both to return "1" and the node. But I did see > in the > > spec the > > > notion of "InScopeNamespaces". I generally hate reading > specs > > like these > > > so I am not very knowledgeable about what the spec says. > > > > > > HTH, > > > -Alex > > > > > > On 9/4/19, 11:05 AM, "Greg Dove" <[email protected]> > wrote: > > > > > > 'Have you rummaged through the spec?' > > > Yes, if anything I probably need to step away from it > and > > experience > > > the > > > world a bit more! I have been focused on each portion > of the > > spec as I > > > create unit tests and verify things between the player > and > > the Royale > > > implementation. > > > I've also glanced a few times in the avmplus code, and > that > > has > > > provided > > > some clues where things were intentionally implemented > > slightly off > > > spec, > > > but still a few things to figure out. However I am > making > > progress - I > > > think I have everything covered for the codebase I am > > working on.... > > > but I > > > will keep going beyond that. For that example above, I > might > > be wrong, > > > but > > > I suspect it is using a multiname with default > namespace > > included for > > > the > > > explicit call case in the player, but not for the > implicit > > one, but I > > > am > > > not yet sure why. I will double-check the spec > though... > > > > > > > > > On Thu, Sep 5, 2019 at 4:02 AM Alex Harui > > <[email protected]> > > > wrote: > > > > > > > Don't know. Have you rummaged through the spec? > > > > > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ecma-international.org%2Fpublications%2Ffiles%2FECMA-ST-WITHDRAWN%2FEcma-357.pdf&data=02%7C01%7Caharui%40adobe.com%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637033071564533291&sdata=N1f5b20jjPP4SHWNM4hyleXMJW6qW%2FItnmgJ7oU73Hs%3D&reserved=0 > > > > > > > > HTH, > > > > -Alex > > > > > > > > On 9/4/19, 3:11 AM, "Greg Dove" <[email protected] > > > > wrote: > > > > > > > > This is particularly for Harbs and Yishay, as I > think > > you are > > > both (or > > > > both > > > > have been) using XML quite a bit. I have quite a > few > > fixes > > > coming. All > > > > with tests that match on swf and js. > > > > > > > > I am currently working to demonstrate proof of > concept > > to a > > > prospective > > > > client for migration of a Flex app. The app makes > > extensive use > > > of e4x > > > > and > > > > uses a bunch of features that I expect had not > > received attention > > > > previously, because they were originally either > not > > working with > > > the > > > > codebase I am porting, or i think some even > caused > > errors in the > > > > javascript > > > > output. > > > > > > > > So I have spent the last several days almost > full time > > figuring > > > things > > > > out > > > > and working on fixes, between the compiler and > > emulation classes. > > > > All the previous XML tests continue to pass, but > I > > have many > > > more unit > > > > tests and fixes lined up for the following: > > > > > > > > namespace directives > > > > default xml namespace > > > > use namespace (multiple) > > > > > > > > a number of fixes for xml filtering, including: > > > > -'this' resolves correctly in filters that > include > > external > > > references > > > > from > > > > the fitler expression to the 'this' scope > > > > -handles alternate ordering of comparisons > between XML > > 'getters' > > > and > > > > literals > > > > e.g. something.(name() = "cat") or > something.("cat" = > > name()) > > > (these > > > > are > > > > the same) > > > > -it (will) now handle XML e4x references in > nested > > function calls > > > > inside > > > > the filter, e.g. things like: > > > > e.g. > > > > var people:XML = <people> > > > > <person> > > > > <name>Bob</name> > > > > <age>32</age> > > > > </person> > > > > <person> > > > > <name>Joe</name> > > > > <age>46</age> > > > > </person> > > > > </people>; > > > > var findJoeByAge:Function = function > (i:int):Boolean { > > > > return i > 40; > > > > }; > > > > people.person.(findJoeByAge(parseInt(age))).name > > > > > > > > > > > > I have lots more granular tests in QName, > Namespace, > > and XML with > > > > tuning to > > > > improve reliability. > > > > toXMLString XML node output also matches flash > more > > correctly in > > > what I > > > > have coming. > > > > > > > > One thing that I am trying to figure out, which > I would > > > appreciate > > > > input on > > > > if someone has an answer: > > > > For the example: > > > > > > > > var feed:XML = new XML( > > > > '<feed xmlns:atom=" > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&data=02%7C01%7Caharui%40adobe.com%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%3D&reserved=0 > > > > " > > > > xmlns:m="nothing">\n' + > > > > ' <link rel="no_namespace" > > > > href="blah/12321/domain/"/>\n' + > > > > '</feed>\n'); > > > > var atomSpace:Namespace = new Namespace(' > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&data=02%7C01%7Caharui%40adobe.com%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%3D&reserved=0 > > > ' > > > > ); > > > > > > > > Can anyone explain why this (in SWF, as a > reference > > > implementation): > > > > trace(feed.atomSpace::link.length()) > > > > trace(feed.atomSpace::link.toXMLString()) > > > > //output: > > > > 0 > > > > {empty string} > > > > is different to: > > > > trace(feed.child(new > QName(atomSpace,'link')).length()) > > > > trace(feed.child(new > > QName(atomSpace,'link')).toXMLString()) > > > > //output: > > > > 1 > > > > <link rel="no_namespace" > href="blah/12321/domain/" > > xmlns:atom=" > > > > > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.w3.org%2F2005%2FAtom&data=02%7C01%7Caharui%40adobe.com%7C69f67b4b1dc44a06a78f08d7323413bc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637033071564533291&sdata=l%2FaBdWHEKCOV%2ByL6NAaE6TFmOokIkA1nZNooLp0Ens0%3D&reserved=0 > > > " > > > > xmlns:m="nothing"/> > > > > > > > > I had assumed the above cases would be the same, > but > > the second > > > one is > > > > behaving as if it has the default namespace > included > > with the > > > specified > > > > namespace in the QName matching (it does > correctly > > match the > > > namespace > > > > specifically as well -with e.g. <atom:link nodes > where > > the > > > prefix atom > > > > is > > > > bound to the uri, but also seems to include link > nodes > > with the > > > default > > > > namespace, whether or not it is declared). I can > > accommodate this > > > > difference to make them behave the same, I just > would > > like to > > > > understand > > > > the basis for the actual rules if anyone > knows.... > > > > > > > > I should be in a position to push the updates > this > > coming > > > weekend I > > > > think. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
