Of course, my suggestion of using event.target.myXML.child(“foo”) will only work if we do not prepend _as3_.
Actually, prepending will break any use of XML methods for non-typed XML. On Nov 16, 2015, at 10:51 AM, Harbs <harbs.li...@gmail.com> wrote: > 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++. >>> >> >
