flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: [FALCONJX][FLEXJS] XML handling (was Re: [FlexJS] Back port)
Date Sun, 15 Nov 2015 16:49:38 GMT
BTW, how are we handling “for each” loops?

On Nov 12, 2015, at 11:43 PM, Alex Harui <aharui@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.lists@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 <aharui@adobe.com> wrote:
>> 
>>> 
>>> 
>>> On 11/12/15, 12:48 PM, "Harbs" <harbs.lists@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
>>> 
>> 
> 


Mime
View raw message