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