I just made a commit which should do the right thing vis a vis both undefined
and empty strings.
I added a test for the additional case and all existing tests still pass...
> On Jul 4, 2022, at 2:28 PM, Harbs <harbs.li...@gmail.com> wrote:
>
> 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?
>>>>
>>>>
>>
>
