BTW, how are we handling “for each” loops?
On Nov 12, 2015, at 11:43 PM, Alex Harui <aha...@adobe.com> wrote:
> 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
>>>
>>
>
