This seems like a partial solution. The thing with dot notation, is that you can use anything — even elements that do not exist. You have a mismatch between your xml and your code. In your example, xml.committer will return an XMLList with two elements. xml.employee will return an XMLList with a length() of 0. Unless we map the dot notation to child() in the compiler, we will get a LOT of errors in existing E4X code. Checking xml.element.length() is a very common way of checking that an element exists.
I guess we could use defineProperty for the cases when the Type of the XML is not clear to the compiler, but even then, it will only work if the client code is only checking elements which exist. It seems to me that consistently failing on non-typed XML is easier to deal with then sometimes-yes- sometimes-no access. But I could imagine others disagree. FWIW, we can make the following recommendations: 1. Use a local variable which has its type set for XML: var lis:XMLList = event.target.myXML; trace(list.foo); 2. Use type casting: trace((event.target.myXML as XMLList).foo); or trace(XMLList(event.target.myXML).foo); 3. When the type is not defined, use .child(): trace(event.target.myXML.child(“foo”)); On Nov 16, 2015, at 7:31 AM, Alex Harui <aha...@adobe.com> wrote: > > > On 11/15/15, 7:55 AM, "Harbs" <harbs.li...@gmail.com> wrote: > >> Right, but I don’t see any way around this. Simple property access will >> not work for the reasons I wrote above. > > My thinking was that, for some XML like: > > <project> > <committer id=“1”> > <firstname>Alex</firstname> > <lastname>Harui</lastname> > </committer > > < committer id=“2”> > <firstname>Peter</firstname> > <lastname>Ent</lastname> > </committer > > <product id=“1”> > <name>Flex</name> > </product> > <product id=“2”> > <name>FlexJS</name> > </product> > </project> > > that you would instantiate an XML instance, and defineProperties employee > and product with getters that call child(“employee”) and child(“product”) > respectively. > > The XMLList returned from child(“employee”) would have defineProperties > for “1”, “2”, and also “firstname” and “lastname”. > The XMLList returned from child(“product”) would have defineProperties for > “1”, “2”, and also “name”, which is why I was thinking we would want the > name() function to be _as3_name(). > > Of course, I could be missing something. I always figured that XML and > XMLList use something like flash_proxy underneath, where it could detect > any reads and writes from an instance. There is no such thing in JS as > far as I know, so the best we can do is defineProperties that we know we > need so we can detect reads and writes on them. > > > -Alex > > >> >> >> On Nov 15, 2015, at 5:49 PM, Alex Harui <aha...@adobe.com> wrote: >> >>> The compiler does not know that myXML is from myClass so it would simply >>> add a property access to foo. Now we could require that folks more >>> strongly type their code by adding in >>> >>> trace((event.target.myXML as XMLList).foo); >>> >>> >>> But we might get complaints. The fact we normally don’t need all that >>> casting is what can make AS more efficient than languages that require >>> the >>> casting like Java and C++. >> >
