You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Harbs <ha...@gmail.com> on 2022/06/26 15:09:41 UTC
XML.conversion
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?
Re: XML.conversion
Posted by Harbs <ha...@gmail.com>.
That also depends on the targetObject and targetProperty values.
It’s only undefined if there’s no targetObject OR there IS a targetProperty.
> On Jul 4, 2022, at 5:36 PM, Greg Dove <gr...@gmail.com> wrote:
>
> An empty
> XMLList does not equal an empty string (it does equal undefined)
Re: XML.conversion
Posted by Harbs <ha...@gmail.com>.
I already forgot the details, but I’m pretty sure that the tests I added covered this.
> On Jul 11, 2022, at 9:05 AM, Greg Dove <gr...@gmail.com> wrote:
>
> I finally got back to this over my weekend. There were additional cases
> like var n:Number = Number(xmlListRefThatIsNull) and quite a few other
> edge cases.
>
> There is an alternative to Language.string just for XMLList which is used
> if the value could be valid null, and if a null check is assumed to be not
> needed (because there is a 'chain' and null at the beginning would cause a
> runtime error in both VMs) then a String() coercion is used instead (which
> forces toString instead of valueOf).
>
> You can see a bunch of tests here:
> https://github.com/apache/royale-asjs/blob/a259b4e4ce567313a8289df98ab500f65c97c174/frameworks/projects/XML/src/test/royale/flexUnitTests/xml/XMLListTesterGeneralTest.as#L420
>
> As a quick follow-on, Harbs, in terms of the equality behavior:
> re: "That also depends on the targetObject and targetProperty values.
> It’s only undefined if there’s no targetObject OR there IS a
> targetProperty."
>
> Do you have some test cases for this? I didn't quite 'get' this... if you
> have test cases that define this please add them (with [Ignore] metadata if
> they are failing) so I can address anything that is not working as it
> should be.
>
>
>
>
>
> On Tue, Jul 5, 2022 at 5:55 PM Greg Dove <gr...@gmail.com> wrote:
>
>>
>> I have most of it working:
>>
>> public function testEmptyListCoercion():void{
>> var node:XML = <type type="without name
>> attribute"><val>2</val></type>;
>>
>> var list:XMLList = node.@name;
>>
>> var str:String = list;
>> assertTrue(str == '');
>>
>> str = 'test'+list;
>> assertTrue(str == 'test');
>>
>> var n:Number = Number(list); //WIP
>> assertTrue(n == 0);
>>
>> n = 1+list;
>> assertTrue(n == 1);
>>
>> var b:Boolean = Boolean(list);
>> assertTrue(b === true);
>>
>> b = list || false;
>> assertTrue(b === true);
>>
>> //non-empty coercion example
>> list = node.val;
>> n = 1+list; // this should be string concatentation ultimately
>> coerced to Number
>> assertTrue(n === 12);
>> }
>>
>> Everything is passing there except for the
>> var n:Number = Number(list);
>> marked WIP and I am close with that also. There was no need to use
>> XMLList.plus, but so far I am coercing xmlish and non-xmlish concatenation
>> with String(xmlish) (and not with Language.string which triggers valueOf).
>> I guess I need to check more complex concatenations with 3 or more elements
>> being added as well.
>>
>> I will try to get it in tomorrow before I start my normal work hours.
>>
>>
>>
>> On Tue, Jul 5, 2022 at 8:49 AM Greg Dove <gr...@gmail.com> wrote:
>>
>>>
>>> I will look into it today.
>>>
>>> Unfortunately the instance level 'plus' method is not suitable for the
>>> general case, because an XMLList reference can also be null which would
>>> cause an error in the generated js code that would not be present in AVM,
>>> although this is an edge case. But it does mean that for the general case,
>>> if there is not native support via valueOf or toString etc, then it is
>>> better to route things through a static method that covers the edge cases.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jul 5, 2022 at 8:26 AM Harbs <ha...@gmail.com> wrote:
>>>
>>>> It looks like BinaryOperatorEmitter is supposed to be emitting .plus(),
>>>> but it doesn’t seem to be doing so…
>>>>
>>>> Harbs
>>>>
>>>>> On Jul 4, 2022, at 6:32 PM, Harbs <ha...@gmail.com> wrote:
>>>>>
>>>>> The logic should be something like this in pseudocode:
>>>>>
>>>>> if(isPlus && (isXMLish(righthand) || isXMLish(leftHand){
>>>>> if(isXM<Lish(leftHand){
>>>>> //output lefthand.plus(righthand)
>>>>> }else{
>>>>> // output righthand.plus(lefthand)
>>>>> }
>>>>>
>>>>>> On Jul 4, 2022, at 6:25 PM, Harbs <harbs.lists@gmail.com <mailto:
>>>> harbs.lists@gmail.com>> wrote:
>>>>>>
>>>>>> I think the compiler should be using the “plus” XML method for string
>>>> concatenation of XML.
>>>>>>
>>>>>>> On Jul 4, 2022, at 5:36 PM, Greg Dove <greg.dove@gmail.com <mailto:
>>>> greg.dove@gmail.com>> wrote:
>>>>>>>
>>>>>>> (it does equal undefined), but it
>>>>>>> seems it does concatenate as an empty string.
>>>>>>
>>>>>
>>>>
>>>>
Re: XML.conversion
Posted by Greg Dove <gr...@gmail.com>.
I finally got back to this over my weekend. There were additional cases
like var n:Number = Number(xmlListRefThatIsNull) and quite a few other
edge cases.
There is an alternative to Language.string just for XMLList which is used
if the value could be valid null, and if a null check is assumed to be not
needed (because there is a 'chain' and null at the beginning would cause a
runtime error in both VMs) then a String() coercion is used instead (which
forces toString instead of valueOf).
You can see a bunch of tests here:
https://github.com/apache/royale-asjs/blob/a259b4e4ce567313a8289df98ab500f65c97c174/frameworks/projects/XML/src/test/royale/flexUnitTests/xml/XMLListTesterGeneralTest.as#L420
As a quick follow-on, Harbs, in terms of the equality behavior:
re: "That also depends on the targetObject and targetProperty values.
It’s only undefined if there’s no targetObject OR there IS a
targetProperty."
Do you have some test cases for this? I didn't quite 'get' this... if you
have test cases that define this please add them (with [Ignore] metadata if
they are failing) so I can address anything that is not working as it
should be.
On Tue, Jul 5, 2022 at 5:55 PM Greg Dove <gr...@gmail.com> wrote:
>
> I have most of it working:
>
> public function testEmptyListCoercion():void{
> var node:XML = <type type="without name
> attribute"><val>2</val></type>;
>
> var list:XMLList = node.@name;
>
> var str:String = list;
> assertTrue(str == '');
>
> str = 'test'+list;
> assertTrue(str == 'test');
>
> var n:Number = Number(list); //WIP
> assertTrue(n == 0);
>
> n = 1+list;
> assertTrue(n == 1);
>
> var b:Boolean = Boolean(list);
> assertTrue(b === true);
>
> b = list || false;
> assertTrue(b === true);
>
> //non-empty coercion example
> list = node.val;
> n = 1+list; // this should be string concatentation ultimately
> coerced to Number
> assertTrue(n === 12);
> }
>
> Everything is passing there except for the
> var n:Number = Number(list);
> marked WIP and I am close with that also. There was no need to use
> XMLList.plus, but so far I am coercing xmlish and non-xmlish concatenation
> with String(xmlish) (and not with Language.string which triggers valueOf).
> I guess I need to check more complex concatenations with 3 or more elements
> being added as well.
>
> I will try to get it in tomorrow before I start my normal work hours.
>
>
>
> On Tue, Jul 5, 2022 at 8:49 AM Greg Dove <gr...@gmail.com> wrote:
>
>>
>> I will look into it today.
>>
>> Unfortunately the instance level 'plus' method is not suitable for the
>> general case, because an XMLList reference can also be null which would
>> cause an error in the generated js code that would not be present in AVM,
>> although this is an edge case. But it does mean that for the general case,
>> if there is not native support via valueOf or toString etc, then it is
>> better to route things through a static method that covers the edge cases.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Jul 5, 2022 at 8:26 AM Harbs <ha...@gmail.com> wrote:
>>
>>> It looks like BinaryOperatorEmitter is supposed to be emitting .plus(),
>>> but it doesn’t seem to be doing so…
>>>
>>> Harbs
>>>
>>> > On Jul 4, 2022, at 6:32 PM, Harbs <ha...@gmail.com> wrote:
>>> >
>>> > The logic should be something like this in pseudocode:
>>> >
>>> > if(isPlus && (isXMLish(righthand) || isXMLish(leftHand){
>>> > if(isXM<Lish(leftHand){
>>> > //output lefthand.plus(righthand)
>>> > }else{
>>> > // output righthand.plus(lefthand)
>>> > }
>>> >
>>> >> On Jul 4, 2022, at 6:25 PM, Harbs <harbs.lists@gmail.com <mailto:
>>> harbs.lists@gmail.com>> wrote:
>>> >>
>>> >> I think the compiler should be using the “plus” XML method for string
>>> concatenation of XML.
>>> >>
>>> >>> On Jul 4, 2022, at 5:36 PM, Greg Dove <greg.dove@gmail.com <mailto:
>>> greg.dove@gmail.com>> wrote:
>>> >>>
>>> >>> (it does equal undefined), but it
>>> >>> seems it does concatenate as an empty string.
>>> >>
>>> >
>>>
>>>
Re: XML.conversion
Posted by Greg Dove <gr...@gmail.com>.
I have most of it working:
public function testEmptyListCoercion():void{
var node:XML = <type type="without name
attribute"><val>2</val></type>;
var list:XMLList = node.@name;
var str:String = list;
assertTrue(str == '');
str = 'test'+list;
assertTrue(str == 'test');
var n:Number = Number(list); //WIP
assertTrue(n == 0);
n = 1+list;
assertTrue(n == 1);
var b:Boolean = Boolean(list);
assertTrue(b === true);
b = list || false;
assertTrue(b === true);
//non-empty coercion example
list = node.val;
n = 1+list; // this should be string concatentation ultimately
coerced to Number
assertTrue(n === 12);
}
Everything is passing there except for the
var n:Number = Number(list);
marked WIP and I am close with that also. There was no need to use
XMLList.plus, but so far I am coercing xmlish and non-xmlish concatenation
with String(xmlish) (and not with Language.string which triggers valueOf).
I guess I need to check more complex concatenations with 3 or more elements
being added as well.
I will try to get it in tomorrow before I start my normal work hours.
On Tue, Jul 5, 2022 at 8:49 AM Greg Dove <gr...@gmail.com> wrote:
>
> I will look into it today.
>
> Unfortunately the instance level 'plus' method is not suitable for the
> general case, because an XMLList reference can also be null which would
> cause an error in the generated js code that would not be present in AVM,
> although this is an edge case. But it does mean that for the general case,
> if there is not native support via valueOf or toString etc, then it is
> better to route things through a static method that covers the edge cases.
>
>
>
>
>
>
>
>
> On Tue, Jul 5, 2022 at 8:26 AM Harbs <ha...@gmail.com> wrote:
>
>> It looks like BinaryOperatorEmitter is supposed to be emitting .plus(),
>> but it doesn’t seem to be doing so…
>>
>> Harbs
>>
>> > On Jul 4, 2022, at 6:32 PM, Harbs <ha...@gmail.com> wrote:
>> >
>> > The logic should be something like this in pseudocode:
>> >
>> > if(isPlus && (isXMLish(righthand) || isXMLish(leftHand){
>> > if(isXM<Lish(leftHand){
>> > //output lefthand.plus(righthand)
>> > }else{
>> > // output righthand.plus(lefthand)
>> > }
>> >
>> >> On Jul 4, 2022, at 6:25 PM, Harbs <harbs.lists@gmail.com <mailto:
>> harbs.lists@gmail.com>> wrote:
>> >>
>> >> I think the compiler should be using the “plus” XML method for string
>> concatenation of XML.
>> >>
>> >>> On Jul 4, 2022, at 5:36 PM, Greg Dove <greg.dove@gmail.com <mailto:
>> greg.dove@gmail.com>> wrote:
>> >>>
>> >>> (it does equal undefined), but it
>> >>> seems it does concatenate as an empty string.
>> >>
>> >
>>
>>
Re: XML.conversion
Posted by Greg Dove <gr...@gmail.com>.
I will look into it today.
Unfortunately the instance level 'plus' method is not suitable for the
general case, because an XMLList reference can also be null which would
cause an error in the generated js code that would not be present in AVM,
although this is an edge case. But it does mean that for the general case,
if there is not native support via valueOf or toString etc, then it is
better to route things through a static method that covers the edge cases.
On Tue, Jul 5, 2022 at 8:26 AM Harbs <ha...@gmail.com> wrote:
> It looks like BinaryOperatorEmitter is supposed to be emitting .plus(),
> but it doesn’t seem to be doing so…
>
> Harbs
>
> > On Jul 4, 2022, at 6:32 PM, Harbs <ha...@gmail.com> wrote:
> >
> > The logic should be something like this in pseudocode:
> >
> > if(isPlus && (isXMLish(righthand) || isXMLish(leftHand){
> > if(isXM<Lish(leftHand){
> > //output lefthand.plus(righthand)
> > }else{
> > // output righthand.plus(lefthand)
> > }
> >
> >> On Jul 4, 2022, at 6:25 PM, Harbs <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>
> >> I think the compiler should be using the “plus” XML method for string
> concatenation of XML.
> >>
> >>> On Jul 4, 2022, at 5:36 PM, Greg Dove <greg.dove@gmail.com <mailto:
> greg.dove@gmail.com>> wrote:
> >>>
> >>> (it does equal undefined), but it
> >>> seems it does concatenate as an empty string.
> >>
> >
>
>
Re: XML.conversion
Posted by Harbs <ha...@gmail.com>.
It looks like BinaryOperatorEmitter is supposed to be emitting .plus(), but it doesn’t seem to be doing so…
Harbs
> On Jul 4, 2022, at 6:32 PM, Harbs <ha...@gmail.com> wrote:
>
> The logic should be something like this in pseudocode:
>
> if(isPlus && (isXMLish(righthand) || isXMLish(leftHand){
> if(isXM<Lish(leftHand){
> //output lefthand.plus(righthand)
> }else{
> // output righthand.plus(lefthand)
> }
>
>> On Jul 4, 2022, at 6:25 PM, Harbs <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>
>> I think the compiler should be using the “plus” XML method for string concatenation of XML.
>>
>>> On Jul 4, 2022, at 5:36 PM, Greg Dove <greg.dove@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> (it does equal undefined), but it
>>> seems it does concatenate as an empty string.
>>
>
Re: XML.conversion
Posted by Harbs <ha...@gmail.com>.
The logic should be something like this in pseudocode:
if(isPlus && (isXMLish(righthand) || isXMLish(leftHand){
if(isXM<Lish(leftHand){
//output lefthand.plus(righthand)
}else{
// output righthand.plus(lefthand)
}
> On Jul 4, 2022, at 6:25 PM, Harbs <ha...@gmail.com> wrote:
>
> I think the compiler should be using the “plus” XML method for string concatenation of XML.
>
>> On Jul 4, 2022, at 5:36 PM, Greg Dove <greg.dove@gmail.com <ma...@gmail.com>> wrote:
>>
>> (it does equal undefined), but it
>> seems it does concatenate as an empty string.
>
Re: XML.conversion
Posted by Harbs <ha...@gmail.com>.
I think the compiler should be using the “plus” XML method for string concatenation of XML.
> On Jul 4, 2022, at 5:36 PM, Greg Dove <gr...@gmail.com> wrote:
>
> (it does equal undefined), but it
> seems it does concatenate as an empty string.
Re: XML.conversion
Posted by Greg Dove <gr...@gmail.com>.
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, <ha...@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 <ha...@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 <ha...@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 <gr...@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, <ha...@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 <ha...@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 <ha...@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 <gr...@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 <ha...@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 <ha...@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?
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >
>
>
Re: XML.conversion
Posted by Harbs <ha...@gmail.com>.
The spec says that valueOf is supposed to return the XML object, so maybe comparison uses valueOf, but string concatenation then uses toString()?
> On Jul 4, 2022, at 5:24 PM, Harbs <ha...@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 <ha...@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 <ha...@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 <gr...@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, <ha...@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 <ha...@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 <ha...@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 <gr...@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 <ha...@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 <ha...@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?
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
>
Re: XML.conversion
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ha...@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 <gr...@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, <ha...@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 <ha...@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 <ha...@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 <gr...@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 <ha...@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 <ha...@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?
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>
Re: XML.conversion
Posted by Harbs <ha...@gmail.com>.
But that case seems to fail in Flash, so it’s likely correct...
> On Jul 4, 2022, at 5:14 PM, Harbs <ha...@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 <gr...@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, <ha...@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 <ha...@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 <ha...@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 <gr...@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 <ha...@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 <ha...@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?
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>
>
Re: XML.conversion
Posted by Harbs <ha...@gmail.com>.
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 <gr...@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, <ha...@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 <ha...@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 <ha...@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 <gr...@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 <ha...@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 <ha...@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?
>>>>>>
>>>>>>
>>>>
>>>
>>
>>
Re: XML.conversion
Posted by Greg Dove <gr...@gmail.com>.
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, <ha...@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 <ha...@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 <ha...@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 <gr...@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 <ha...@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 <ha...@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?
> >>>>
> >>>>
> >>
> >
>
>
Re: XML.conversion
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ha...@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 <gr...@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 <ha...@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 <ha...@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?
>>>>
>>>>
>>
>
Re: XML.conversion
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <gr...@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 <ha...@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 <ha...@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?
>>>
>>>
>
Re: XML.conversion
Posted by Harbs <ha...@gmail.com>.
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 <gr...@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 <ha...@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 <ha...@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?
>>
>>
Re: XML.conversion
Posted by Greg Dove <gr...@gmail.com>.
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 <ha...@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 <ha...@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?
>
>
Re: XML.conversion
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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?