OK, it’s a deal. I will look into some changes to the compiler.
I think the changes are:
1) XML literals will call "new XML(literal_as_string)" and your code will
parse the string
2) delete on XMLList will call _as3_removeChild() but delete on XML just
does delete
3) all function calls on XML and XMLList will be prepended with “_as3_”
4) .. will result in calls to _as3_descendants()
5) @ will result in a call to _as3_attribute()
6) filters (@attr == “bar”) results in a call to
_as3_filter(Function(node:XML):Boolean)
Can we put of #6 for a while? Did I leave anything out?
-Alex
On 11/12/15, 1:34 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>Prepending a decoration might work. I’d probably pick something like
>“_as3_” rather than “AS3” for the reason that it looks more like a
>prepend to the name and it makes the unlikely chance that someone has an
>element with the prepended namespace even more unlikely.
>
>defineProperty with one extra index might work. I’ll give that a go…
>
>On Nov 12, 2015, at 11:18 PM, Alex Harui <aha...@adobe.com> wrote:
>
>>
>>
>> On 11/12/15, 12:48 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>
>>> 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.
>>
>> I’m worried that proxy-ing properties to an internal object will result
>>in
>> performance problems, bloat the code, make it harder to debug on the JS
>> side (should you need to). Having properties on the XML instance itself
>> would probably let code run correctly where we didn’t know it was XML
>>(and
>> thought it was Object).
>>
>> I just noticed that in Flash, the XML methods are in the AS3 namespace,
>> which is why they don’t collide with the child “name” tag. I think it
>> might be easier to catch that the function call resolved to that
>>namespace
>> and prepend a decoration on the function name.
>>
>> Then you would write your XML class as:
>>
>> public class XML()
>> {
>> public function AS3name():XMLList
>> {
>> ..
>> }
>> }
>>
>>>
>>> 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.
>>
>> Well, if you find the defineProperties trick acceptable, I think it
>>would
>> work in most of these cases.
>>
>> Thoughts?
>> -Alex
>>
>
