On Nov 15, 2015, at 4:55 PM, Alex Harui <aha...@adobe.com> wrote: > > > On 11/15/15, 12:45 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> I was not thinking very clearly last week when we had this discussion. >> We’re missing a very important piece here: >> >> xml.foo returns an XMLList and not an XML object. If you have some xml >> like this: <root><foo id=“1”/><baz id=“1”/><foo id=“2”/></root>, xml.foo >> will give you an XMLList with 2 foo elements xml.baz will give you an >> XMLList with 1 element, and xml.children() will give you an XMLList with >> all three in the order of foo@id=1,baz@id=1 and foo@id=2. >> >> Using simple object notation will not work correctly for this because >> there can be only one object per key. Using arrays or array-like objects >> (xml.foo = [foo@id=1,foo@id=2]) will not work either because we need to >> keep the order of elements (i.e. baz needs to be between the two foos) >> >> Additionally, calling xmlList.foo will return an XMLList of all foo >> elements of all the XML objects in the XMLList. >> >> So, here’s how I think we need to handle this: >> >> 1. XML.foo() or XMLList.foo(), the code should remain .foo() on the JS >> side. I do not see any need to add the _as3_ prepend. >> 2. XML.foo or XMLList.foo, that should become XML.child(‘foo”) and >> XMLList.child(“foo”). >> 3. XML.@foo and XMLList.@foo should become XML.attribute(“foo”) and >> XMLList.attribute(“foo”). > > I will look #2 and #3. > > For #1, my thoughts were that you would not use Array as the base class > for XML and XMLList and instead populate it via defineProperties with > indexes. You could also populate it with defineProperties for known child > tag names and have the getter call child() or attribute(). They advantage > of that is that it would work in more cases where the developer has not > strongly typed their code. But if you do that, you would need those _as3_ > prefixes.
I’m with you on the defineProperties on XMLList. I’ve already started working on that. I’m not sure what that has to do with the prefixes. My point is that if we’re not using simple object notation to reference elements, but we strictly use .child() instead, there will be no conflicts with function calls. As long as there’s no functions which use numbers, we should have no conflicts. Am I missing something? >> >> I’m not totally clear on exactly how we’re going to handle all the >> filters. I think we still need some discussion on that, but let’s get the >> basics straight first. > > The proposal is that you add an _as3_filter() function to XMLList. It > takes a function. You pass that function each node and it returns true or > false. Right. I’m just not totally sure how the expressions get converted into the function calls and what the function calls will look like. E4X expressions can get pretty “expressive”… ;-)
