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