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
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
