Re: Breaking Compiler Change

2019-02-20 Thread Harbs
It exists to make Flex uses compatible with Royale when the type could not be determined. It’s possible that the new coercions might make it no longer necessary, but this whole thread started because the XML split method was still being called, so I’m not sure that we’re there yet… > On Feb 20

Re: Breaking Compiler Change

2019-02-19 Thread Josh Tynjala
Here is where it is defined in Royale: https://github.com/apache/royale-asjs/blob/e02f896f3510a90aff00d852dac4401e2705fcf3/frameworks/projects/XML/src/main/royale/XML.as#L2767 It does not exist in Flash. I'm trying to determine why it exists in Royale and if it's still necessary. - Josh On 201

Re: Breaking Compiler Change

2019-02-19 Thread Alex Harui
I'm confused. Where is the ASDoc for XML.split? On 2/19/19, 2:41 PM, "Josh Tynjala" wrote: I was just playing around with XML in Flash, and I tried this code: var xml:XML = ; var parts:Array = xml.split("/"); It compiles, but I get the following runtime error:

Re: Breaking Compiler Change

2019-02-19 Thread Josh Tynjala
I was just playing around with XML in Flash, and I tried this code: var xml:XML = ; var parts:Array = xml.split("/"); It compiles, but I get the following runtime error: > TypeError: Error #1006: value is not a function. To work in Flash, I need to assign the XML instance to a String first so t

Re: Breaking Compiler Change

2019-02-19 Thread Alex Harui
FWIW, I'm not sure I've followed this, but it may help to mention that, IMO, Closure has started to strictly-type the externs for the browser APIs. Which may be undesirable for some folks. So one option is to create an alternative to JS.swc which does have more "*"s in the APIs. HTH, -Alex 

Re: Breaking Compiler Change

2019-02-19 Thread Josh Tynjala
In the Closure compiler externs, it's an optional number: @param {number=} opt_limit In pure JS, that technically allows you to pass in both undefined or a number, but I think that the fact that undefined is not included directly also signals a certain intent for it to be stricter. However, it

Re: Breaking Compiler Change

2019-02-19 Thread Harbs
The methods in XML are there to allow XML to behave as if it’s a String or a Number. In JS, the signature of split is "undefined|Number". That becomes “*” in AS3 considering AS3 does not have “dual” types. > On Feb 19, 2019, at 8:59 PM, Josh Tynjala wrote: > > My gut feeling would be to stri

Re: Breaking Compiler Change

2019-02-19 Thread Josh Tynjala
My gut feeling would be to strive for consistency in how the automatic type conversion behaves. If some function calls have it, and others don't, that's potentially confusing. Someone used to AS3 behavior might expect undefined to become NaN, and they'll wonder why it didn't happen in one place

Re: Breaking Compiler Change

2019-02-19 Thread Harbs
I did not mean that Number(undefined) shouldn’t become NaN. That’s correct behavior. I was questioning the coercion here. I already changed XML to used bracketed access for this problem. I’m not thrilled about passing in a number to split. My gut tells me that it’s probably slower than undefine

Re: Breaking Compiler Change

2019-02-19 Thread Josh Tynjala
I tested the following code in Flash: var num:Number = undefined; trace(num); //NaN Assigning undefined to a Number results in NaN in Flash. The XML signature for split() should probably look like this instead: split(delimiter:* = undefined, limit:Number = 0x7fff):Array It looks like Strin

Re: Breaking Compiler Change

2019-02-10 Thread Harbs
:08:14 PM > To: dev@royale.apache.org > Subject: Re: Breaking Compiler Change > > Found it in XML: > >public function > split(separator:*=undefined,limit:*=undefined):Array >{ >return s().split(separator,limit);

RE: Breaking Compiler Change

2019-02-10 Thread Yishay Weiss
Would it make sense to change the signature to public function split(separator:*=undefined,limit:int=0):Array ? From: Harbs Sent: Sunday, February 10, 2019 1:08:14 PM To: dev@royale.apache.org Subject: Re: Breaking Compiler Change Found

Re: Breaking Compiler Change

2019-02-10 Thread Harbs
Found it in XML: public function split(separator:*=undefined,limit:*=undefined):Array { return s().split(separator,limit); } Becomes: XML.prototype.split = function(separator, limit) { separator = typeof separator !== 'un

Re: Breaking Compiler Change

2019-02-10 Thread Harbs
The problem appears to be fd7b81f4448db0f5eb70f22208c9144549cc4806 I’m still trying to track down exactly where it’s breaking… > On Feb 10, 2019, at 12:11 AM, Harbs wrote: > > Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6 > > I’ll try to track it down tomorrow… > >> On Feb 9, 2019,

Re: Breaking Compiler Change

2019-02-09 Thread Harbs
Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6 I’ll try to track it down tomorrow… > On Feb 9, 2019, at 11:54 PM, Harbs wrote: > > FYI: One of the compiler change in the last few days broke my app. > > I’m not yet positive which commit it is, but I think it’s > ad2e39d4e1ea129cd10557

Breaking Compiler Change

2019-02-09 Thread Harbs
FYI: One of the compiler change in the last few days broke my app. I’m not yet positive which commit it is, but I think it’s ad2e39d4e1ea129cd10557b877b5ae80a12928e6 My app works with 87ed9852674f0148f8ed0da659714172979e48d1 I’ll post more observations tomorrow… Harbs