You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Harbs <ha...@gmail.com> on 2018/11/18 16:28:52 UTC
XML methods
Xml has the following two methods:
getAttributeArray() and getChildrenArray()
These do not exist in the E4X spec, but I added them to get the underlying attribute and children of an XML object to make it possible to add performance optimizations in JS if desired.
Currently in returns a copy of the arrays, but I’m thinking that it should really return the original array to prevent extra garbage collection if the purpose of these methods are for optimization.
Any objections to me making this change?
Harbs
Re: XML methods
Posted by Harbs <ha...@gmail.com>.
> but if your new methods are used to generate the attributes() XMLList
They aren’t.
> "is anybody using these new methods?”
Besides me, I doubt it.
But I don’t want to recklessly change things without at least mentioning the change...
> On Nov 19, 2018, at 2:30 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> I haven't looked at the code, but if your new methods are used to generate the attributes() XMLList, then I would think that migrating Flex users would have to care. (and if not, I would want to know why it sounds like there are two ways to build up the list of attributes) If these are truly new to Royale, the better first question probably should have been "is anybody using these new methods?"
>
> -Alex
>
> On 11/19/18, 11:26 AM, "Harbs" <ha...@gmail.com> wrote:
>
> Existing code doesn’t need to care. These methods are new and don’t exist in Flash.
>
>> On Nov 19, 2018, at 2:23 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>>
>> On 11/19/18, 11:20 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> Trying to “delete” (or access) a specific element of the XMLList while manipulating the array is something that would need care.
>>
>> I think that's my point. I think existing code in migrating Flex apps didn't need to care, so they shouldn't have to care in Royale by default. But if you provide an option where they trade-off caring for speed, that seems fine to me.
>>
>> -Alex
>>
>
>
>
Re: XML methods
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I haven't looked at the code, but if your new methods are used to generate the attributes() XMLList, then I would think that migrating Flex users would have to care. (and if not, I would want to know why it sounds like there are two ways to build up the list of attributes) If these are truly new to Royale, the better first question probably should have been "is anybody using these new methods?"
-Alex
On 11/19/18, 11:26 AM, "Harbs" <ha...@gmail.com> wrote:
Existing code doesn’t need to care. These methods are new and don’t exist in Flash.
> On Nov 19, 2018, at 2:23 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
>
> On 11/19/18, 11:20 AM, "Harbs" <ha...@gmail.com> wrote:
>
> Trying to “delete” (or access) a specific element of the XMLList while manipulating the array is something that would need care.
>
> I think that's my point. I think existing code in migrating Flex apps didn't need to care, so they shouldn't have to care in Royale by default. But if you provide an option where they trade-off caring for speed, that seems fine to me.
>
> -Alex
>
Re: XML methods
Posted by Harbs <ha...@gmail.com>.
Existing code doesn’t need to care. These methods are new and don’t exist in Flash.
> On Nov 19, 2018, at 2:23 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
>
> On 11/19/18, 11:20 AM, "Harbs" <ha...@gmail.com> wrote:
>
> Trying to “delete” (or access) a specific element of the XMLList while manipulating the array is something that would need care.
>
> I think that's my point. I think existing code in migrating Flex apps didn't need to care, so they shouldn't have to care in Royale by default. But if you provide an option where they trade-off caring for speed, that seems fine to me.
>
> -Alex
>
Re: XML methods
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 11/19/18, 11:20 AM, "Harbs" <ha...@gmail.com> wrote:
Trying to “delete” (or access) a specific element of the XMLList while manipulating the array is something that would need care.
I think that's my point. I think existing code in migrating Flex apps didn't need to care, so they shouldn't have to care in Royale by default. But if you provide an option where they trade-off caring for speed, that seems fine to me.
-Alex
Re: XML methods
Posted by Harbs <ha...@gmail.com>.
That specific loop will work.
When dealing with the array directly, “delete” is not necessary.
Removing all the attributes would be as simple as:
xml.getAttributeArray().length = 0;
Trying to “delete” (or access) a specific element of the XMLList while manipulating the array is something that would need care.
> On Nov 19, 2018, at 1:14 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> The specific case I was thinking of was a loop where you delete attributes. Are you sure that loop would work?
>
> Var xml:XML = new XML('<node a="1" b="2" c="3" d="4" e="5" />');
> Var attrList:XMLList = xml.attributes();
> Var n:Int = attrList.length();
> For (var i:int = 0; I < n; i++)
> delete xml[attrList[i]];
>
> If attrList shrinks as you delete attributes, this code should fail.
>
> If there is no code internal to XML/XMLList that deletes things from the list in loops, then maybe you only need to clone the array when passing it "outside of the implementation" such as the result of attributes().
>
> If you want to add another custom XML Processing Flag that says Delete won't work (or requires that delete loops always go backward) then it can be an option.
>
> My 2 cents,
> -Alex
>
> On 11/19/18, 2:28 AM, "Harbs" <ha...@gmail.com> wrote:
>
> The reason I originally made it return a copy was to make it immutable, but I’m finding it useful to avoid overhead of creating temporary XMLLists. It has a measurable effect on performance. Modifying the XML using the underlying arrays (i.e. allowing mutability) should have similar performance benefits.
>
> There’s no “state” in the XML other than the arrays of children and attributes. (Well I guess namespaces too, but that’s pretty rare to be an issue.) To me it seems that allowing the option of using “sharp knives” on things outside the E4X spec are worth the the risk of cutting yourself… ;-)
>
> Harbs
>
>> On Nov 18, 2018, at 11:58 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>>
>> No objections from me if it will still work. Is there any expectation about immutability of the array? If you are iterating it and the loop executes some other operation on the XML, could it change the array and mess up the iteration?
>>
>> -Alex
>>
>> On 11/18/18, 8:29 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> Xml has the following two methods:
>>
>> getAttributeArray() and getChildrenArray()
>>
>> These do not exist in the E4X spec, but I added them to get the underlying attribute and children of an XML object to make it possible to add performance optimizations in JS if desired.
>>
>> Currently in returns a copy of the arrays, but I’m thinking that it should really return the original array to prevent extra garbage collection if the purpose of these methods are for optimization.
>>
>> Any objections to me making this change?
>>
>> Harbs
>>
>
>
>
Re: XML methods
Posted by Alex Harui <ah...@adobe.com.INVALID>.
The specific case I was thinking of was a loop where you delete attributes. Are you sure that loop would work?
Var xml:XML = new XML('<node a="1" b="2" c="3" d="4" e="5" />');
Var attrList:XMLList = xml.attributes();
Var n:Int = attrList.length();
For (var i:int = 0; I < n; i++)
delete xml[attrList[i]];
If attrList shrinks as you delete attributes, this code should fail.
If there is no code internal to XML/XMLList that deletes things from the list in loops, then maybe you only need to clone the array when passing it "outside of the implementation" such as the result of attributes().
If you want to add another custom XML Processing Flag that says Delete won't work (or requires that delete loops always go backward) then it can be an option.
My 2 cents,
-Alex
On 11/19/18, 2:28 AM, "Harbs" <ha...@gmail.com> wrote:
The reason I originally made it return a copy was to make it immutable, but I’m finding it useful to avoid overhead of creating temporary XMLLists. It has a measurable effect on performance. Modifying the XML using the underlying arrays (i.e. allowing mutability) should have similar performance benefits.
There’s no “state” in the XML other than the arrays of children and attributes. (Well I guess namespaces too, but that’s pretty rare to be an issue.) To me it seems that allowing the option of using “sharp knives” on things outside the E4X spec are worth the the risk of cutting yourself… ;-)
Harbs
> On Nov 18, 2018, at 11:58 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> No objections from me if it will still work. Is there any expectation about immutability of the array? If you are iterating it and the loop executes some other operation on the XML, could it change the array and mess up the iteration?
>
> -Alex
>
> On 11/18/18, 8:29 AM, "Harbs" <ha...@gmail.com> wrote:
>
> Xml has the following two methods:
>
> getAttributeArray() and getChildrenArray()
>
> These do not exist in the E4X spec, but I added them to get the underlying attribute and children of an XML object to make it possible to add performance optimizations in JS if desired.
>
> Currently in returns a copy of the arrays, but I’m thinking that it should really return the original array to prevent extra garbage collection if the purpose of these methods are for optimization.
>
> Any objections to me making this change?
>
> Harbs
>
Re: XML methods
Posted by Harbs <ha...@gmail.com>.
The reason I originally made it return a copy was to make it immutable, but I’m finding it useful to avoid overhead of creating temporary XMLLists. It has a measurable effect on performance. Modifying the XML using the underlying arrays (i.e. allowing mutability) should have similar performance benefits.
There’s no “state” in the XML other than the arrays of children and attributes. (Well I guess namespaces too, but that’s pretty rare to be an issue.) To me it seems that allowing the option of using “sharp knives” on things outside the E4X spec are worth the the risk of cutting yourself… ;-)
Harbs
> On Nov 18, 2018, at 11:58 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> No objections from me if it will still work. Is there any expectation about immutability of the array? If you are iterating it and the loop executes some other operation on the XML, could it change the array and mess up the iteration?
>
> -Alex
>
> On 11/18/18, 8:29 AM, "Harbs" <ha...@gmail.com> wrote:
>
> Xml has the following two methods:
>
> getAttributeArray() and getChildrenArray()
>
> These do not exist in the E4X spec, but I added them to get the underlying attribute and children of an XML object to make it possible to add performance optimizations in JS if desired.
>
> Currently in returns a copy of the arrays, but I’m thinking that it should really return the original array to prevent extra garbage collection if the purpose of these methods are for optimization.
>
> Any objections to me making this change?
>
> Harbs
>
Re: XML methods
Posted by Alex Harui <ah...@adobe.com.INVALID>.
No objections from me if it will still work. Is there any expectation about immutability of the array? If you are iterating it and the loop executes some other operation on the XML, could it change the array and mess up the iteration?
-Alex
On 11/18/18, 8:29 AM, "Harbs" <ha...@gmail.com> wrote:
Xml has the following two methods:
getAttributeArray() and getChildrenArray()
These do not exist in the E4X spec, but I added them to get the underlying attribute and children of an XML object to make it possible to add performance optimizations in JS if desired.
Currently in returns a copy of the arrays, but I’m thinking that it should really return the original array to prevent extra garbage collection if the purpose of these methods are for optimization.
Any objections to me making this change?
Harbs