Yes the first one of those is the reason that it is tricky. An empty
XMLList does not equal an empty string (it does equal undefined), but it
seems it does concatenate as an empty string.
I will look at this tomorrow, we do have some client code that relies on
the undefined equality behavior and recently discovered the issue with the
string concatenation behavior also.
On Tue, 5 Jul 2022, 2:25 am 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?
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >
>
>
