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 <[email protected]> wrote: > I'm confused. Where is the ASDoc for XML.split? > > On 2/19/19, 2:41 PM, "Josh Tynjala" <[email protected]> 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 <[email protected]> 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 <[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 > > >>>>>> > > >>>>> > > >>>> > > >>>> > > >> > > >> > > > > > > >
