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