The spec says that valueOf is supposed to return the XML object, so maybe
comparison uses valueOf, but string concatenation then uses toString()?
> On Jul 4, 2022, at 5:24 PM, Harbs <harbs.li...@gmail.com> wrote:
>
> OK. Here’s something to look at:
>
> xml = <xml><Properties name="baz"><foo/></Properties></xml>;
> var props:XMLList = xml.Properties;
> var bar:XMLList = xml.Bar;
> This assert fails in Flash
> assertEquals(bar , "","bar should evaluate to an empty string”);
> with:
> <failure message="expected <> to be equal to <> - bar should
> evaluate to an empty string"
> type="flexUnitTests.xml::XMLTesterStringifyTest.emptyStringify"><![CDATA[Error:
> expected <> to be equal to <> - bar should evaluate to an empty string
> Not sure why…
>
> This passes in Flash and fails in JS:
> assertEquals(""+bar , "","bar should evaluate to an empty string");
>
>
>> On Jul 4, 2022, at 5:19 PM, Harbs <harbs.li...@gmail.com> wrote:
>>
>> But that case seems to fail in Flash, so it’s likely correct...
>>
>>> On Jul 4, 2022, at 5:14 PM, Harbs <harbs.li...@gmail.com> wrote:
>>>
>>> My test case covered what I found (assertEquals("" + xml.Baz.text(), "","An
>>> empty node should return an empty string”);)
>>>
>>> Here’s another case which I did not retest after my changes:
>>>
>>> var xml = <xml><Properties name="baz"><foo/></Properties></xml>;
>>> var props:XMLList = xml.Properties;
>>> trace(props.length())// 1
>>> var bar:XMLList = xml.Bar;
>>> if(bar && bar != ""){
>>> trace("bar should not be undefined and we should not get here!!!");
>>> }
>>>
>>>
>>>> On Jul 4, 2022, at 4:56 PM, Greg Dove <greg.d...@gmail.com> wrote:
>>>>
>>>> Thanks Harbs. By coincidence, I was actually intending to work on exactly
>>>> the same thing tomorrow local time, because Yishay encountered something
>>>> similar and I also wanted to create a failing test to fix.
>>>>
>>>> It's definitely a bit tricky. iirc it was something like this:
>>>>
>>>> var list:XMLList;
>>>>
>>>> list == null ; // not surprising
>>>> var node:XML = <xml/>;
>>>> list = node.@nonexistent;
>>>>
>>>> list == undefined // true
>>>> list == null // false, failing I think at the moment in js
>>>> 'test' + list +'test' == 'testtest'//this I had captured in prep also and
>>>> I think this is what you covered? There was another case where
>>>> Language.string was causing it I think also, which I had asked Yishay for
>>>> the example of just a few hours ago.
>>>>
>>>> If you see any more related to this please feel free to add failing tests
>>>> marked with ignore Metadata for now and I will happily work on them.
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, 5 Jul 2022, 12:32 am Harbs, <harbs.li...@gmail.com> wrote:
>>>>
>>>>> 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?
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>
