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 >
