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 <greg.d...@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 <greg.d...@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 <harbs.li...@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 <harbs.li...@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.li...@gmail.com <mailto: >>> harbs.li...@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.d...@gmail.com <mailto: >>> greg.d...@gmail.com>> wrote: >>> >>> >>> >>> (it does equal undefined), but it >>> >>> seems it does concatenate as an empty string. >>> >> >>> > >>> >>>
