I was not thinking very clearly last week when we had this discussion. We’re
missing a very important piece here:
xml.foo returns an XMLList and not an XML object. If you have some xml like
this: <root><foo id=“1”/><baz id=“1”/><foo id=“2”/></root>, xml.foo will give
you an XMLList with 2 foo elements xml.baz will give you an XMLList with 1
element, and xml.children() will give you an XMLList with all three in the
order of foo@id=1,baz@id=1 and foo@id=2.
Using simple object notation will not work correctly for this because there can
be only one object per key. Using arrays or array-like objects (xml.foo =
[foo@id=1,foo@id=2]) will not work either because we need to keep the order of
elements (i.e. baz needs to be between the two foos)
Additionally, calling xmlList.foo will return an XMLList of all foo elements of
all the XML objects in the XMLList.
So, here’s how I think we need to handle this:
1. XML.foo() or XMLList.foo(), the code should remain .foo() on the JS side. I
do not see any need to add the _as3_ prepend.
2. XML.foo or XMLList.foo, that should become XML.child(‘foo”) and
XMLList.child(“foo”).
3. XML.@foo and XMLList.@foo should become XML.attribute(“foo”) and
XMLList.attribute(“foo”).
I’m not totally clear on exactly how we’re going to handle all the filters. I
think we still need some discussion on that, but let’s get the basics straight
first.
Harbs
On Nov 12, 2015, at 11:58 PM, Harbs <harbs.li...@gmail.com> wrote:
> That looks like about it.
>
> Putting off #6 is fine for now.
>
> 7) We’re also going to have to map any XML function call to the version with
> the prepend.
>
> I have a really busy weekend (my son’s bar mitzvah is this week), so it’s
> likely that I’m not going to have anything to commit until sometime next week.
>
> I’m glad we found something that looks like it should work.
>
> Harbs
>
> 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
>>>>
>>>
>>
>
