It’s because valueOf of XMLList was changed.
For reference, this passed in Flash and fails in JS:
public function emptyStringify():void{
var xml:XML = <Foo><Baz/></Foo>;
assertEquals("" + xml.Baz.text(), "","An empty node should return
an empty string");
}
> On Jul 4, 2022, at 2:01 PM, Harbs <harbs.li...@gmail.com> wrote:
>
> There’s more xml problems.
>
> Coercing empty xml to a string used to result in an empty string. It now
> results in “undefined”.
>
> i.e.
>
> var xml:XML = <Foo><Baz/></Foo>;
> '' + xml.Baz.text()
>
> I believe we used to get “”, and now we get “undefined”.
>
>> On Jun 27, 2022, at 6:44 AM, Greg Dove <greg.d...@gmail.com> wrote:
>>
>> Sorry about that, Harbs.
>>
>> "I’m guessing XML(_children[i]) really was meant to be: (_children[i] as
>> XML)..."
>>
>> That was some time ago, but I also think you are correct with the guess.
>>
>> I probably had a momentary lapse of thought and forgot that
>> XML(something) ]
>> does not get ignored by @royaleignorecoercion XML, and that you need
>> instead to always use
>> "as XML"
>> for @royaleignorecoercion to work with XML. I think Array is similar in
>> this regard, with the native 'class' being a top level function.
>>
>> In general I have added more of these explicit coercions because the
>> framework has a lot of compiler switch tweaks which sometimes makes it
>> unworkable to copy and paste the framework code as a monkey patch alongside
>> external project code. By adding the explicit coercion and the
>> "royaleignoring" it, there is no implicit coercion code generated under
>> default compiler behaviour, for example, so it makes a default compiler
>> settings build closer to the framework settings build of it.
>> I find this use of monkey patching to be any easy way to test changes to
>> many framework classes in the context of their actual usage, as it avoids
>> recompiling the library first to test small changes each time, before
>> ultimately bringing the changes back into the library code.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jun 27, 2022 at 3:19 AM Harbs <harbs.li...@gmail.com> wrote:
>>
>>> I changed the class to allow subclassing.
>>>
>>> I don’t think I messed anything up. I’m guessing XML(_children[i]) really
>>> was meant to be: (_children[i] as XML)...
>>>
>>> Harbs
>>>
>>>> On Jun 26, 2022, at 6:09 PM, Harbs <harbs.li...@gmail.com> wrote:
>>>>
>>>> I just noticed that the changes to XML using XML.conversion broke my app.
>>>>
>>>> I have an optimization where I subclass XML and override toString and
>>> toXMLString so there’s no need to create, parse and convert many parts of
>>> XML which don’t need that.
>>>>
>>>> I call it StringXML.
>>>>
>>>> This code:
>>>>
>>> strArr.push(XML.conversion(this._children[i])._toXMLString(nextIndentLevel,
>>> declarations.concat(ancestors)));
>>>>
>>>> causes my instance to go through XML.conversion and ends up with this:
>>> return new XML(xml); where xml is a StringXML.
>>>>
>>>> That obviously does not work.
>>>>
>>>> What is the purpose of calling conversion on an XML node?
>>>>
>>>> That’s caused by
>>> strArr.push(XML(_children[i])._toXMLString(nextIndentLevel,declarations.concat(ancestors)));
>>>>
>>>> The compiler changes XML to XML.conversion.
>>>>
>>>> I don’t understand why that change was made.
>>>>
>>>> The code originally looked like:
>>>>
>>>>
>>> strArr.push(_children[i].toXMLString(nextIndentLevel,ancestors.concat(declarations)));
>>>>
>>>> Greg, any input?
>>>
>>>
>
