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 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 cas
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
I have most of it working:
public function testEmptyListCoercion():void{
var node:XML = 2;
var list:XMLList = node.@name;
var str:String = list;
assertTrue(str == '');
str = 'test'+list;
assertTrue(str == 'test');
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 f
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 wrote:
>
> The logic should be something like this in pseudocode:
>
> if(isPlus && (isXMLish(righthand) || isXMLish(leftHand){
> if(isXM //outp
The logic should be something like this in pseudocode:
if(isPlus && (isXMLish(righthand) || isXMLish(leftHand){
if(isXM On Jul 4, 2022, at 6:25 PM, Harbs 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, Gr
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 wrote:
>
> (it does equal undefined), but it
> seems it does concatenate as an empty string.
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 wrote:
>
> An empty
> XMLList does not equal an empty string (it does equal undefined)
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 r
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 wrote:
>
> OK. Here’s something to look at:
>
>xml = ;
>var props:XMLList = xml.Properti
OK. Here’s something to look at:
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:
;> 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
>>>
oring" 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 b
t; >>> 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
> >>> ulti
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 change
tual 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
at 3:19 AM Harbs 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:0
t to be: (_children[i] as XML)...
>
> Harbs
>
> > On Jun 26, 2022, at 6:09 PM, Harbs 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
> to
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 wrote:
>
> I just noticed that the changes to XML using XML.conversion broke my ap
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
20 matches
Mail list logo
