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?
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>
