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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>>>>> >>>>>> Nope. It’s not ad2e39d4e1ea129cd10557b877b5ae80a12928e6 >>>>>> >>>>>> I’ll try to track it down tomorrow… >>>>>> >>>>>>> On Feb 9, 2019, at 11:54 PM, Harbs <[email protected]> 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 >>>>>> >>>>> >>>> >>>> >> >>
