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 2019/02/09 21:54:56 UTC
Breaking Compiler Change
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
Re: Breaking Compiler Change
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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
On 2/19/19, 11:34 AM, "Josh Tynjala" <jo...@apache.org> wrote:
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 could be argued that I'm "reading tea leaves" a bit here.
I will say that it's a little odd to me is that we're getting coercion at all here. If the signature of XML's split() and String's split() are the same, then values should pass through unchanged. It's behaving as if String's split() types the parameter as Number. I would expect the two signatures should match, if XML is supposed to be treated the same as String.
- Josh
On 2019/02/19 19:15:27, Harbs <ha...@gmail.com> wrote:
> 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 <jo...@apache.org> wrote:
> >
> > 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 when it happens in others. (That particular one may be rare, but some of the other conversions will definitely be expected to have consistency, like converting to int or String).
> >
> > I guess what I don't understand it this: Why is the limit parameter typed as * here?
> >
> > split(delimiter:* = undefined, limit:* = undefined):Array
> >
> > To me, there doesn't seem to be any reason to accept non-numeric values for limit. This seems like a perfect situation to take advantage of typing because that's why we've chosen AS3 over JS.
> >
> > - Josh
> >
> > On 2019/02/19 17:36:23, Harbs <ha...@gmail.com> wrote:
> >> 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 undefined. (Although for XML methods it’s probably not that big a deal.)
> >>
> >> I’m more concerned about client code. Native JS methods don’t really have the same signatures as Flash ones and JS is pretty good about handling all kinds of data types correctly. I’m wondering if it really makes sense to coerce types that are passed into native JS methods.
> >>
> >> Thoughts?
> >> Harbs
> >>
> >>> On Feb 19, 2019, at 5:17 PM, Josh Tynjala <jo...@apache.org> wrote:
> >>>
> >>> 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 = 0x7fffffff):Array
> >>>
> >>> It looks like String defines the limit parameter's type as Number, or this coercion wouldn't be happening, so it would make sense to me for XML to use the same type.
> >>>
> >>> - Josh
> >>>
> >>> On 2019/02/10 11:08:14, Harbs <ha...@gmail.com> wrote:
> >>>> 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 !== 'undefined' ? separator : undefined;
> >>>> limit = typeof limit !== 'undefined' ? limit : undefined;
> >>>> return this.XML_s().split(separator, Number(limit));
> >>>> };
> >>>>
> >>>> Number(limit) (i.e. Number(undefined) is becoming NaN.
> >>>>
> >>>> Harbs
> >>>>
> >>>>> On Feb 10, 2019, at 11:00 AM, Harbs <ha...@gmail.com> wrote:
> >>>>>
> >>>>> 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 <ha...@gmail.com> wrote:
> >>>>>>
> >>>>>> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> >>>>>>
> >>>>>> I’ll try to track it down tomorrow…
> >>>>>>
> >>>>>>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> >>>>>>>
> >>>>>>> My app works with
> >>>>>>> 87ed9852674f0148f8ed0da659714172979e48d1
> >>>>>>>
> >>>>>>> I’ll post more observations tomorrow…
> >>>>>>>
> >>>>>>> Harbs
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: Breaking Compiler Change
Posted by Josh Tynjala <jo...@apache.org>.
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 could be argued that I'm "reading tea leaves" a bit here.
I will say that it's a little odd to me is that we're getting coercion at all here. If the signature of XML's split() and String's split() are the same, then values should pass through unchanged. It's behaving as if String's split() types the parameter as Number. I would expect the two signatures should match, if XML is supposed to be treated the same as String.
- Josh
On 2019/02/19 19:15:27, Harbs <ha...@gmail.com> wrote:
> 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 <jo...@apache.org> wrote:
> >
> > 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 when it happens in others. (That particular one may be rare, but some of the other conversions will definitely be expected to have consistency, like converting to int or String).
> >
> > I guess what I don't understand it this: Why is the limit parameter typed as * here?
> >
> > split(delimiter:* = undefined, limit:* = undefined):Array
> >
> > To me, there doesn't seem to be any reason to accept non-numeric values for limit. This seems like a perfect situation to take advantage of typing because that's why we've chosen AS3 over JS.
> >
> > - Josh
> >
> > On 2019/02/19 17:36:23, Harbs <ha...@gmail.com> wrote:
> >> 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 undefined. (Although for XML methods it’s probably not that big a deal.)
> >>
> >> I’m more concerned about client code. Native JS methods don’t really have the same signatures as Flash ones and JS is pretty good about handling all kinds of data types correctly. I’m wondering if it really makes sense to coerce types that are passed into native JS methods.
> >>
> >> Thoughts?
> >> Harbs
> >>
> >>> On Feb 19, 2019, at 5:17 PM, Josh Tynjala <jo...@apache.org> wrote:
> >>>
> >>> 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 = 0x7fffffff):Array
> >>>
> >>> It looks like String defines the limit parameter's type as Number, or this coercion wouldn't be happening, so it would make sense to me for XML to use the same type.
> >>>
> >>> - Josh
> >>>
> >>> On 2019/02/10 11:08:14, Harbs <ha...@gmail.com> wrote:
> >>>> 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 !== 'undefined' ? separator : undefined;
> >>>> limit = typeof limit !== 'undefined' ? limit : undefined;
> >>>> return this.XML_s().split(separator, Number(limit));
> >>>> };
> >>>>
> >>>> Number(limit) (i.e. Number(undefined) is becoming NaN.
> >>>>
> >>>> Harbs
> >>>>
> >>>>> On Feb 10, 2019, at 11:00 AM, Harbs <ha...@gmail.com> wrote:
> >>>>>
> >>>>> 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 <ha...@gmail.com> wrote:
> >>>>>>
> >>>>>> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> >>>>>>
> >>>>>> I’ll try to track it down tomorrow…
> >>>>>>
> >>>>>>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> >>>>>>>
> >>>>>>> My app works with
> >>>>>>> 87ed9852674f0148f8ed0da659714172979e48d1
> >>>>>>>
> >>>>>>> I’ll post more observations tomorrow…
> >>>>>>>
> >>>>>>> Harbs
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: Breaking Compiler Change
Posted by Harbs <ha...@gmail.com>.
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, 2019, at 12:57 AM, Josh Tynjala <jo...@apache.org> wrote:
>
> 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 2019/02/19 22:49:03, Alex Harui <ah...@adobe.com.INVALID> wrote:
>> I'm confused. Where is the ASDoc for XML.split?
>>
>> On 2/19/19, 2:41 PM, "Josh Tynjala" <jo...@apache.org> wrote:
>>
>> I was just playing around with XML in Flash, and I tried this code:
>>
>> var xml:XML = <root/>;
>> 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 that the type is coerced.
>>
>> var xml:XML = <root/>;
>> var str:String = xml;
>> var parts:Array = str.split("/");
>>
>> Why exactly does the Royale XML class include these methods from String? Could it be because we were previously missing the automatic type coercion in some situations (like parameters and returns)? Assuming that the coercion correctly handles converting XML to string now, could these methods be safely removed?
>>
>> - Josh
>>
>> On 2019/02/19 19:15:27, Harbs <ha...@gmail.com> wrote:
>>> 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 <jo...@apache.org> wrote:
>>>>
>>>> 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 when it happens in others. (That particular one may be rare, but some of the other conversions will definitely be expected to have consistency, like converting to int or String).
>>>>
>>>> I guess what I don't understand it this: Why is the limit parameter typed as * here?
>>>>
>>>> split(delimiter:* = undefined, limit:* = undefined):Array
>>>>
>>>> To me, there doesn't seem to be any reason to accept non-numeric values for limit. This seems like a perfect situation to take advantage of typing because that's why we've chosen AS3 over JS.
>>>>
>>>> - Josh
>>>>
>>>> On 2019/02/19 17:36:23, Harbs <ha...@gmail.com> wrote:
>>>>> 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 undefined. (Although for XML methods it’s probably not that big a deal.)
>>>>>
>>>>> I’m more concerned about client code. Native JS methods don’t really have the same signatures as Flash ones and JS is pretty good about handling all kinds of data types correctly. I’m wondering if it really makes sense to coerce types that are passed into native JS methods.
>>>>>
>>>>> Thoughts?
>>>>> Harbs
>>>>>
>>>>>> On Feb 19, 2019, at 5:17 PM, Josh Tynjala <jo...@apache.org> wrote:
>>>>>>
>>>>>> 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 = 0x7fffffff):Array
>>>>>>
>>>>>> It looks like String defines the limit parameter's type as Number, or this coercion wouldn't be happening, so it would make sense to me for XML to use the same type.
>>>>>>
>>>>>> - Josh
>>>>>>
>>>>>> On 2019/02/10 11:08:14, Harbs <ha...@gmail.com> wrote:
>>>>>>> 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 !== 'undefined' ? separator : undefined;
>>>>>>> limit = typeof limit !== 'undefined' ? limit : undefined;
>>>>>>> return this.XML_s().split(separator, Number(limit));
>>>>>>> };
>>>>>>>
>>>>>>> Number(limit) (i.e. Number(undefined) is becoming NaN.
>>>>>>>
>>>>>>> Harbs
>>>>>>>
>>>>>>>> On Feb 10, 2019, at 11:00 AM, Harbs <ha...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> 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 <ha...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>>>>>>>>>
>>>>>>>>> I’ll try to track it down tomorrow…
>>>>>>>>>
>>>>>>>>>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>>>>>>>>>>
>>>>>>>>>> My app works with
>>>>>>>>>> 87ed9852674f0148f8ed0da659714172979e48d1
>>>>>>>>>>
>>>>>>>>>> I’ll post more observations tomorrow…
>>>>>>>>>>
>>>>>>>>>> Harbs
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>>
>>
Re: Breaking Compiler Change
Posted by Josh Tynjala <jo...@apache.org>.
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 2019/02/19 22:49:03, Alex Harui <ah...@adobe.com.INVALID> wrote:
> I'm confused. Where is the ASDoc for XML.split?
>
> On 2/19/19, 2:41 PM, "Josh Tynjala" <jo...@apache.org> wrote:
>
> I was just playing around with XML in Flash, and I tried this code:
>
> var xml:XML = <root/>;
> 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 that the type is coerced.
>
> var xml:XML = <root/>;
> var str:String = xml;
> var parts:Array = str.split("/");
>
> Why exactly does the Royale XML class include these methods from String? Could it be because we were previously missing the automatic type coercion in some situations (like parameters and returns)? Assuming that the coercion correctly handles converting XML to string now, could these methods be safely removed?
>
> - Josh
>
> On 2019/02/19 19:15:27, Harbs <ha...@gmail.com> wrote:
> > 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 <jo...@apache.org> wrote:
> > >
> > > 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 when it happens in others. (That particular one may be rare, but some of the other conversions will definitely be expected to have consistency, like converting to int or String).
> > >
> > > I guess what I don't understand it this: Why is the limit parameter typed as * here?
> > >
> > > split(delimiter:* = undefined, limit:* = undefined):Array
> > >
> > > To me, there doesn't seem to be any reason to accept non-numeric values for limit. This seems like a perfect situation to take advantage of typing because that's why we've chosen AS3 over JS.
> > >
> > > - Josh
> > >
> > > On 2019/02/19 17:36:23, Harbs <ha...@gmail.com> wrote:
> > >> 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 undefined. (Although for XML methods it’s probably not that big a deal.)
> > >>
> > >> I’m more concerned about client code. Native JS methods don’t really have the same signatures as Flash ones and JS is pretty good about handling all kinds of data types correctly. I’m wondering if it really makes sense to coerce types that are passed into native JS methods.
> > >>
> > >> Thoughts?
> > >> Harbs
> > >>
> > >>> On Feb 19, 2019, at 5:17 PM, Josh Tynjala <jo...@apache.org> wrote:
> > >>>
> > >>> 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 = 0x7fffffff):Array
> > >>>
> > >>> It looks like String defines the limit parameter's type as Number, or this coercion wouldn't be happening, so it would make sense to me for XML to use the same type.
> > >>>
> > >>> - Josh
> > >>>
> > >>> On 2019/02/10 11:08:14, Harbs <ha...@gmail.com> wrote:
> > >>>> 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 !== 'undefined' ? separator : undefined;
> > >>>> limit = typeof limit !== 'undefined' ? limit : undefined;
> > >>>> return this.XML_s().split(separator, Number(limit));
> > >>>> };
> > >>>>
> > >>>> Number(limit) (i.e. Number(undefined) is becoming NaN.
> > >>>>
> > >>>> Harbs
> > >>>>
> > >>>>> On Feb 10, 2019, at 11:00 AM, Harbs <ha...@gmail.com> wrote:
> > >>>>>
> > >>>>> 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 <ha...@gmail.com> wrote:
> > >>>>>>
> > >>>>>> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> > >>>>>>
> > >>>>>> I’ll try to track it down tomorrow…
> > >>>>>>
> > >>>>>>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> > >>>>>>>
> > >>>>>>> My app works with
> > >>>>>>> 87ed9852674f0148f8ed0da659714172979e48d1
> > >>>>>>>
> > >>>>>>> I’ll post more observations tomorrow…
> > >>>>>>>
> > >>>>>>> Harbs
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>
> > >>
> >
> >
>
>
>
Re: Breaking Compiler Change
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I'm confused. Where is the ASDoc for XML.split?
On 2/19/19, 2:41 PM, "Josh Tynjala" <jo...@apache.org> wrote:
I was just playing around with XML in Flash, and I tried this code:
var xml:XML = <root/>;
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 that the type is coerced.
var xml:XML = <root/>;
var str:String = xml;
var parts:Array = str.split("/");
Why exactly does the Royale XML class include these methods from String? Could it be because we were previously missing the automatic type coercion in some situations (like parameters and returns)? Assuming that the coercion correctly handles converting XML to string now, could these methods be safely removed?
- Josh
On 2019/02/19 19:15:27, Harbs <ha...@gmail.com> wrote:
> 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 <jo...@apache.org> wrote:
> >
> > 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 when it happens in others. (That particular one may be rare, but some of the other conversions will definitely be expected to have consistency, like converting to int or String).
> >
> > I guess what I don't understand it this: Why is the limit parameter typed as * here?
> >
> > split(delimiter:* = undefined, limit:* = undefined):Array
> >
> > To me, there doesn't seem to be any reason to accept non-numeric values for limit. This seems like a perfect situation to take advantage of typing because that's why we've chosen AS3 over JS.
> >
> > - Josh
> >
> > On 2019/02/19 17:36:23, Harbs <ha...@gmail.com> wrote:
> >> 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 undefined. (Although for XML methods it’s probably not that big a deal.)
> >>
> >> I’m more concerned about client code. Native JS methods don’t really have the same signatures as Flash ones and JS is pretty good about handling all kinds of data types correctly. I’m wondering if it really makes sense to coerce types that are passed into native JS methods.
> >>
> >> Thoughts?
> >> Harbs
> >>
> >>> On Feb 19, 2019, at 5:17 PM, Josh Tynjala <jo...@apache.org> wrote:
> >>>
> >>> 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 = 0x7fffffff):Array
> >>>
> >>> It looks like String defines the limit parameter's type as Number, or this coercion wouldn't be happening, so it would make sense to me for XML to use the same type.
> >>>
> >>> - Josh
> >>>
> >>> On 2019/02/10 11:08:14, Harbs <ha...@gmail.com> wrote:
> >>>> 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 !== 'undefined' ? separator : undefined;
> >>>> limit = typeof limit !== 'undefined' ? limit : undefined;
> >>>> return this.XML_s().split(separator, Number(limit));
> >>>> };
> >>>>
> >>>> Number(limit) (i.e. Number(undefined) is becoming NaN.
> >>>>
> >>>> Harbs
> >>>>
> >>>>> On Feb 10, 2019, at 11:00 AM, Harbs <ha...@gmail.com> wrote:
> >>>>>
> >>>>> 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 <ha...@gmail.com> wrote:
> >>>>>>
> >>>>>> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> >>>>>>
> >>>>>> I’ll try to track it down tomorrow…
> >>>>>>
> >>>>>>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> >>>>>>>
> >>>>>>> My app works with
> >>>>>>> 87ed9852674f0148f8ed0da659714172979e48d1
> >>>>>>>
> >>>>>>> I’ll post more observations tomorrow…
> >>>>>>>
> >>>>>>> Harbs
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: Breaking Compiler Change
Posted by Josh Tynjala <jo...@apache.org>.
I was just playing around with XML in Flash, and I tried this code:
var xml:XML = <root/>;
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 that the type is coerced.
var xml:XML = <root/>;
var str:String = xml;
var parts:Array = str.split("/");
Why exactly does the Royale XML class include these methods from String? Could it be because we were previously missing the automatic type coercion in some situations (like parameters and returns)? Assuming that the coercion correctly handles converting XML to string now, could these methods be safely removed?
- Josh
On 2019/02/19 19:15:27, Harbs <ha...@gmail.com> wrote:
> 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 <jo...@apache.org> wrote:
> >
> > 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 when it happens in others. (That particular one may be rare, but some of the other conversions will definitely be expected to have consistency, like converting to int or String).
> >
> > I guess what I don't understand it this: Why is the limit parameter typed as * here?
> >
> > split(delimiter:* = undefined, limit:* = undefined):Array
> >
> > To me, there doesn't seem to be any reason to accept non-numeric values for limit. This seems like a perfect situation to take advantage of typing because that's why we've chosen AS3 over JS.
> >
> > - Josh
> >
> > On 2019/02/19 17:36:23, Harbs <ha...@gmail.com> wrote:
> >> 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 undefined. (Although for XML methods it’s probably not that big a deal.)
> >>
> >> I’m more concerned about client code. Native JS methods don’t really have the same signatures as Flash ones and JS is pretty good about handling all kinds of data types correctly. I’m wondering if it really makes sense to coerce types that are passed into native JS methods.
> >>
> >> Thoughts?
> >> Harbs
> >>
> >>> On Feb 19, 2019, at 5:17 PM, Josh Tynjala <jo...@apache.org> wrote:
> >>>
> >>> 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 = 0x7fffffff):Array
> >>>
> >>> It looks like String defines the limit parameter's type as Number, or this coercion wouldn't be happening, so it would make sense to me for XML to use the same type.
> >>>
> >>> - Josh
> >>>
> >>> On 2019/02/10 11:08:14, Harbs <ha...@gmail.com> wrote:
> >>>> 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 !== 'undefined' ? separator : undefined;
> >>>> limit = typeof limit !== 'undefined' ? limit : undefined;
> >>>> return this.XML_s().split(separator, Number(limit));
> >>>> };
> >>>>
> >>>> Number(limit) (i.e. Number(undefined) is becoming NaN.
> >>>>
> >>>> Harbs
> >>>>
> >>>>> On Feb 10, 2019, at 11:00 AM, Harbs <ha...@gmail.com> wrote:
> >>>>>
> >>>>> 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 <ha...@gmail.com> wrote:
> >>>>>>
> >>>>>> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> >>>>>>
> >>>>>> I’ll try to track it down tomorrow…
> >>>>>>
> >>>>>>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> >>>>>>>
> >>>>>>> My app works with
> >>>>>>> 87ed9852674f0148f8ed0da659714172979e48d1
> >>>>>>>
> >>>>>>> I’ll post more observations tomorrow…
> >>>>>>>
> >>>>>>> Harbs
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: Breaking Compiler Change
Posted by Harbs <ha...@gmail.com>.
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 <jo...@apache.org> wrote:
>
> 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 when it happens in others. (That particular one may be rare, but some of the other conversions will definitely be expected to have consistency, like converting to int or String).
>
> I guess what I don't understand it this: Why is the limit parameter typed as * here?
>
> split(delimiter:* = undefined, limit:* = undefined):Array
>
> To me, there doesn't seem to be any reason to accept non-numeric values for limit. This seems like a perfect situation to take advantage of typing because that's why we've chosen AS3 over JS.
>
> - Josh
>
> On 2019/02/19 17:36:23, Harbs <ha...@gmail.com> wrote:
>> 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 undefined. (Although for XML methods it’s probably not that big a deal.)
>>
>> I’m more concerned about client code. Native JS methods don’t really have the same signatures as Flash ones and JS is pretty good about handling all kinds of data types correctly. I’m wondering if it really makes sense to coerce types that are passed into native JS methods.
>>
>> Thoughts?
>> Harbs
>>
>>> On Feb 19, 2019, at 5:17 PM, Josh Tynjala <jo...@apache.org> wrote:
>>>
>>> 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 = 0x7fffffff):Array
>>>
>>> It looks like String defines the limit parameter's type as Number, or this coercion wouldn't be happening, so it would make sense to me for XML to use the same type.
>>>
>>> - Josh
>>>
>>> On 2019/02/10 11:08:14, Harbs <ha...@gmail.com> wrote:
>>>> 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 !== 'undefined' ? separator : undefined;
>>>> limit = typeof limit !== 'undefined' ? limit : undefined;
>>>> return this.XML_s().split(separator, Number(limit));
>>>> };
>>>>
>>>> Number(limit) (i.e. Number(undefined) is becoming NaN.
>>>>
>>>> Harbs
>>>>
>>>>> On Feb 10, 2019, at 11:00 AM, Harbs <ha...@gmail.com> wrote:
>>>>>
>>>>> 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 <ha...@gmail.com> wrote:
>>>>>>
>>>>>> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>>>>>>
>>>>>> I’ll try to track it down tomorrow…
>>>>>>
>>>>>>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>>>>>>>
>>>>>>> My app works with
>>>>>>> 87ed9852674f0148f8ed0da659714172979e48d1
>>>>>>>
>>>>>>> I’ll post more observations tomorrow…
>>>>>>>
>>>>>>> Harbs
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
Re: Breaking Compiler Change
Posted by Josh Tynjala <jo...@apache.org>.
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 when it happens in others. (That particular one may be rare, but some of the other conversions will definitely be expected to have consistency, like converting to int or String).
I guess what I don't understand it this: Why is the limit parameter typed as * here?
split(delimiter:* = undefined, limit:* = undefined):Array
To me, there doesn't seem to be any reason to accept non-numeric values for limit. This seems like a perfect situation to take advantage of typing because that's why we've chosen AS3 over JS.
- Josh
On 2019/02/19 17:36:23, Harbs <ha...@gmail.com> wrote:
> 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 undefined. (Although for XML methods it’s probably not that big a deal.)
>
> I’m more concerned about client code. Native JS methods don’t really have the same signatures as Flash ones and JS is pretty good about handling all kinds of data types correctly. I’m wondering if it really makes sense to coerce types that are passed into native JS methods.
>
> Thoughts?
> Harbs
>
> > On Feb 19, 2019, at 5:17 PM, Josh Tynjala <jo...@apache.org> wrote:
> >
> > 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 = 0x7fffffff):Array
> >
> > It looks like String defines the limit parameter's type as Number, or this coercion wouldn't be happening, so it would make sense to me for XML to use the same type.
> >
> > - Josh
> >
> > On 2019/02/10 11:08:14, Harbs <ha...@gmail.com> wrote:
> >> 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 !== 'undefined' ? separator : undefined;
> >> limit = typeof limit !== 'undefined' ? limit : undefined;
> >> return this.XML_s().split(separator, Number(limit));
> >> };
> >>
> >> Number(limit) (i.e. Number(undefined) is becoming NaN.
> >>
> >> Harbs
> >>
> >>> On Feb 10, 2019, at 11:00 AM, Harbs <ha...@gmail.com> wrote:
> >>>
> >>> 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 <ha...@gmail.com> wrote:
> >>>>
> >>>> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> >>>>
> >>>> I’ll try to track it down tomorrow…
> >>>>
> >>>>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> >>>>>
> >>>>> My app works with
> >>>>> 87ed9852674f0148f8ed0da659714172979e48d1
> >>>>>
> >>>>> I’ll post more observations tomorrow…
> >>>>>
> >>>>> Harbs
> >>>>
> >>>
> >>
> >>
>
>
Re: Breaking Compiler Change
Posted by Harbs <ha...@gmail.com>.
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 undefined. (Although for XML methods it’s probably not that big a deal.)
I’m more concerned about client code. Native JS methods don’t really have the same signatures as Flash ones and JS is pretty good about handling all kinds of data types correctly. I’m wondering if it really makes sense to coerce types that are passed into native JS methods.
Thoughts?
Harbs
> On Feb 19, 2019, at 5:17 PM, Josh Tynjala <jo...@apache.org> wrote:
>
> 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 = 0x7fffffff):Array
>
> It looks like String defines the limit parameter's type as Number, or this coercion wouldn't be happening, so it would make sense to me for XML to use the same type.
>
> - Josh
>
> On 2019/02/10 11:08:14, Harbs <ha...@gmail.com> wrote:
>> 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 !== 'undefined' ? separator : undefined;
>> limit = typeof limit !== 'undefined' ? limit : undefined;
>> return this.XML_s().split(separator, Number(limit));
>> };
>>
>> Number(limit) (i.e. Number(undefined) is becoming NaN.
>>
>> Harbs
>>
>>> On Feb 10, 2019, at 11:00 AM, Harbs <ha...@gmail.com> wrote:
>>>
>>> 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 <ha...@gmail.com> wrote:
>>>>
>>>> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>>>>
>>>> I’ll try to track it down tomorrow…
>>>>
>>>>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>>>>>
>>>>> My app works with
>>>>> 87ed9852674f0148f8ed0da659714172979e48d1
>>>>>
>>>>> I’ll post more observations tomorrow…
>>>>>
>>>>> Harbs
>>>>
>>>
>>
>>
Re: Breaking Compiler Change
Posted by Josh Tynjala <jo...@apache.org>.
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 = 0x7fffffff):Array
It looks like String defines the limit parameter's type as Number, or this coercion wouldn't be happening, so it would make sense to me for XML to use the same type.
- Josh
On 2019/02/10 11:08:14, Harbs <ha...@gmail.com> wrote:
> 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 !== 'undefined' ? separator : undefined;
> limit = typeof limit !== 'undefined' ? limit : undefined;
> return this.XML_s().split(separator, Number(limit));
> };
>
> Number(limit) (i.e. Number(undefined) is becoming NaN.
>
> Harbs
>
> > On Feb 10, 2019, at 11:00 AM, Harbs <ha...@gmail.com> wrote:
> >
> > 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 <ha...@gmail.com> wrote:
> >>
> >> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> >>
> >> I’ll try to track it down tomorrow…
> >>
> >>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
> >>>
> >>> My app works with
> >>> 87ed9852674f0148f8ed0da659714172979e48d1
> >>>
> >>> I’ll post more observations tomorrow…
> >>>
> >>> Harbs
> >>
> >
>
>
Re: Breaking Compiler Change
Posted by Harbs <ha...@gmail.com>.
The Flash signature is:
split(delimiter:*, limit:Number = 0x7fffffff):Array
But the JS signature is (sort of):
split(delimiter:*, limit:* = undefined):Array
I’m wondering if it makes sense to not do coercion on any built-in methods.
Harbs
> On Feb 10, 2019, at 2:20 PM, Yishay Weiss <yi...@hotmail.com> wrote:
>
> Would it make sense to change the signature to
>
>
>
> public function split(separator:*=undefined,limit:int=0):Array
>
>
>
> ?
>
>
>
> ________________________________
> From: Harbs <ha...@gmail.com>
> Sent: Sunday, February 10, 2019 1: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);
> }
>
> Becomes:
>
> XML.prototype.split = function(separator, limit) {
> separator = typeof separator !== 'undefined' ? separator : undefined;
> limit = typeof limit !== 'undefined' ? limit : undefined;
> return this.XML_s().split(separator, Number(limit));
> };
>
> Number(limit) (i.e. Number(undefined) is becoming NaN.
>
> Harbs
>
>> On Feb 10, 2019, at 11:00 AM, Harbs <ha...@gmail.com> wrote:
>>
>> 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 <ha...@gmail.com> wrote:
>>>
>>> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>>>
>>> I’ll try to track it down tomorrow…
>>>
>>>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>>>>
>>>> My app works with
>>>> 87ed9852674f0148f8ed0da659714172979e48d1
>>>>
>>>> I’ll post more observations tomorrow…
>>>>
>>>> Harbs
>>>
>>
>
RE: Breaking Compiler Change
Posted by Yishay Weiss <yi...@hotmail.com>.
Would it make sense to change the signature to
public function split(separator:*=undefined,limit:int=0):Array
?
________________________________
From: Harbs <ha...@gmail.com>
Sent: Sunday, February 10, 2019 1: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);
}
Becomes:
XML.prototype.split = function(separator, limit) {
separator = typeof separator !== 'undefined' ? separator : undefined;
limit = typeof limit !== 'undefined' ? limit : undefined;
return this.XML_s().split(separator, Number(limit));
};
Number(limit) (i.e. Number(undefined) is becoming NaN.
Harbs
> On Feb 10, 2019, at 11:00 AM, Harbs <ha...@gmail.com> wrote:
>
> 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 <ha...@gmail.com> wrote:
>>
>> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>>
>> I’ll try to track it down tomorrow…
>>
>>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>>>
>>> My app works with
>>> 87ed9852674f0148f8ed0da659714172979e48d1
>>>
>>> I’ll post more observations tomorrow…
>>>
>>> Harbs
>>
>
Re: Breaking Compiler Change
Posted by Harbs <ha...@gmail.com>.
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 !== 'undefined' ? separator : undefined;
limit = typeof limit !== 'undefined' ? limit : undefined;
return this.XML_s().split(separator, Number(limit));
};
Number(limit) (i.e. Number(undefined) is becoming NaN.
Harbs
> On Feb 10, 2019, at 11:00 AM, Harbs <ha...@gmail.com> wrote:
>
> 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 <ha...@gmail.com> wrote:
>>
>> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>>
>> I’ll try to track it down tomorrow…
>>
>>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>>>
>>> My app works with
>>> 87ed9852674f0148f8ed0da659714172979e48d1
>>>
>>> I’ll post more observations tomorrow…
>>>
>>> Harbs
>>
>
Re: Breaking Compiler Change
Posted by Harbs <ha...@gmail.com>.
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 <ha...@gmail.com> wrote:
>
> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>
> I’ll try to track it down tomorrow…
>
>> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>>
>> My app works with
>> 87ed9852674f0148f8ed0da659714172979e48d1
>>
>> I’ll post more observations tomorrow…
>>
>> Harbs
>
Re: Breaking Compiler Change
Posted by Harbs <ha...@gmail.com>.
Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6
I’ll try to track it down tomorrow…
> On Feb 9, 2019, at 11:54 PM, Harbs <ha...@gmail.com> 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 ad2e39d4e1ea129cd10557b877b5ae80a12928e6
>
> My app works with
> 87ed9852674f0148f8ed0da659714172979e48d1
>
> I’ll post more observations tomorrow…
>
> Harbs