What I mean was that the dynamic object structure could be a property of XML rather than being XML itself.
So the API would be XML which would have all the necessary functions, but it would keep a living structure as a separate dynamic object. If the compiler could modify all delete operator calls on XML properties to the corresponding dynamic object within, that might solve this issue. Regarding #2: Yes. It’s probably possible to substitute writing to XMLList to modifying XML instead, changing XMLList is VERY common, and if we’re trying to accommodate existing code, there’s going to be lots of bad code. It’s also almost always easier to write to XMLList than it is to XML. Another part of the problem is that I think a lot of folks don’t have the distinction between XMLList and XML clear in certai use cases. This is especially true because single item XMLLists almost always behave as if they are XML objects. On Nov 12, 2015, at 10:36 PM, Alex Harui <aha...@adobe.com> wrote: > I only read this article quickly. I’m not sure what you mean by “proxies > to XML.xmlObj”. > > My takeaway from the article is that the XML class you are writing will > need to handle > > new XML(someString) > > by implementing one of the conversions. I didn’t know about JXON until > you posted the link just now, but I was thinking along the same lines. > The attributes and children would be properties on the XML instance. Then > the delete operator would automatically do the right thing. > > I don’t think the article covered two of the issues you raised: > 1) a child tag <name /> conflicting with the name() function and other > collisions like that. > 2) how to track mutation of an XMLList back to the XML. > > I don’t think e4x-like query results was in the scope of the article. > > I was just looking at how the delete operator gets parsed. I think it > will be possible, if we know the object is XMLList, to call a > removeChild() function. > > The answer for #1 might be similar. We might try to detect function calls > on objects of type XML and XMLList and call the functions with a decorated > name. I should add that doing so wouldn’t help folks who are trying to > use your XML classes from native JS. This approach requires the class > substitutions that FalconJX executes when the SWF version (which uses the > XML and XMLList definitions in playerglobal/airglobal) gets cross-compiled. > > For #2, how bad would it be if the compiler output an error or warning if > folks write to an XMLList. Isn’t there always a way to do the same thing > by direct manipulation of the XML? Otherwise, you might have to resort to > using Object.defineProperties and maybe define one extra index that, when > written to, ands a new extra index. > > Thoughts? > -Alex > > > On 11/12/15, 12:10 PM, "Harbs" <harbs.li...@gmail.com> wrote: > >> BTW, there’s a good JXON doc on MDN here[1] >> >> Maybe there’s some way to have a dynamic object as a property of XML so >> all XML methods could get proxied to XML.xmlObj? >> >> [1]https://developer.mozilla.org/en-US/docs/JXON >> >> On Nov 12, 2015, at 10:02 PM, Harbs <harbs.li...@gmail.com> wrote: >> >>>> So, given all that, if your XML class is dynamic, and attributes are >>>> just >>>> added to the instance as properties with the @prefix and child nodes >>>> are >>>> arrays of the child node name, I think that delete will do the right >>>> thing. >>> >>> Yes. attributes can be prefixed with “@“, but what about element names >>> which might conflict with function names? For example I could easily see >>> someone have some xml which looks like this:<catalog><name >>> title=“something”/></catalog> “name would then conflict with “name()”. >>> >>> I was thinking of having one array of elements and another for >>> properties. Mapping delete to something like that sounds tricky. >> >
