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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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
>
