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" <greg.d...@gmail.com> 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 <aha...@adobe.com.invalid> 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" <aha...@adobe.com.INVALID> 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" <greg.d...@gmail.com> 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
<aha...@adobe.com.invalid>
> 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" <greg.d...@gmail.com> 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
> <aha...@adobe.com.invalid>
> > 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" <greg.d...@gmail.com>
> 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.
> > >
> > >
> > >
> >
> >
> >
>
>
>
>
>
