On Feb 8, 7:32 pm, RobG <rg...@iinet.net.au> wrote:
> On Feb 8, 11:53 pm, kangax <kan...@gmail.com> wrote:
[...]
> > It's not pointless, but the scope of its use is indeed pretty narrow.
>
> Can you provide a scenario where isNumber is more suitable than
> typeof? If not the scope of its usefulness is zero.
Of course. `isNumber` (as it is in a trunk) will return `true` for
Number *object*, while `typeof` will obviously return "object".
Whether Number objects are something that should be present in a
script (rather than simple number primitives) is a different topic.
>
> > Since neither `instanceof` operator nor `constructor` value check can
> > not be relied upon when working with multiple contexts (frames),
> > `Object.isString` is here to "take care" of it.
>
> They test for completely different things. I would guess that if
> instanceof or constructor tests are necessary, typeof is unlikely to
> be a useful replacement regardless of the context. If typeof is a
> suitable replacement, then there was no point in using instanceof et
> al in the first place.
`isNumber` works in multi-frame environment. `instanceof`/
`constructor` don't:
numberObjectFromOtherWindow instanceof Number; // false
Object.isNumber(numberObjectFromOtherWindow); // true
There are obviously other ways to accomplish this; say, first trigger
"ToNumber" and then use `typeof`:
typeof +numberObjectFromOtherWindow; // number
but the point is that `isNumber` works "reliably" in multi-frame
environment, while `instanceof` doesn't.
>
> Can you write an isNumber function that uses instanceof across frames
> successfully? And if so, can you define the time when such
> functionality would be useful?
`instanceof` doesn't work across frames - there's not much we can do.
I personally have almost never worked with frames (and always try to
design them out of the application, as much as requirements allow :))
>
> > AFAIK, ES committee is
> > planning to finally document ECMA behavior in context of multiple
> > global objects.
>
> Great, but irrelevant to the current discussion. Or are you inferring
> that isNumber is simply a placeholder for possibly useful (but as yet
> undefined) future functionality?
`isNumber` is an abstraction level. A noble (but ill-conceived) goal
to unify type checking in diverse Javascript land : ) IIRC, the first
version of `isNumber` looked like - `return typeof object ==
"number"`, and was added for *consistency* with other `Object.is*`
methods - an infamous `isArray` was one of the first ones (following
by others). Right now, I don't believe in generic solutions. The best
way to go is to get familiar with language and use whatever fits the
best. Nevertheless, checking for [[Class]] == "Number" seems to cover
most of what masses desire (I'm also inclined to making `isNumber`
"filter out" `NaN` and `Infinity`)
>
> > > Object.isNumber(NaN); // true
>
> > Should it return `false`?
>
> According to the documentation, no - but the function name suggests
I'm not talking about documentation at this point. I'm interested in
your opinion (but you already said it best few paragraphs down)
> otherwise. Perhaps ‘isNumberType’ more accurately reflects what the
> function does.
Well, the way it's implemented at the moment is by checking object's
[[Class]]. If anything, it should be called "isNumberClass" but then
there's possibility of a confusion with "Class" in its common OOP
sense.
>
> Anyway, it doesn't matter what I think it should return - ask those
> who are its intended user base. Should isNumber('5') return true?
> The documentation says isNumber is a wrapper for typeof, so why not
> just use typeof and save the confusion?
I'd rather change documentation, since as we know by now, `typeof` is
not always sufficient (and whenever it is - it can just be used
explicitly, without resorting to any "higher order" helpers).
>
> > 4.3.23 (NaN) says that "... This value is a member of the Number
> > type.". Also, `typeof NaN == "number"`, NaN's `constructor` is
> > `Number`, its [[Class]] is "Number" and it's [[Prototype]] references
> > `Number.prototype`? Should we return `false` for "practical" reasons?
>
> You're making my argument for me. :-)
>
> All those points are valid and highlight that if one or more of those
> properties are of interest, they should be tested for explicitly.
> There are values that aren't numbers (either Objects or primitives)
> that can be used safely in arithmetic operations and some that are
> numbers that can't.
>
> A function like isNumber can't cover all possibilities unless it
> returns a variety of values depending on the type, constructor, etc.
> and if it was one of those properties that are really of interest, why
> not test for it directly?
Yes. Using the right tool for the job was the morale of my first post
in this thread - "Javascript is actually quite flexible..." : )
>
> > And what should `Object.isNumber` return for +/-Inifinity? Adding
> > `isFinite` to `isNumber` would be able to take care of both - `NaN`
> > and `Infinity` cases.
>
> If the current behaviour is not suitable (it seems to do exactly what
> it is documented to do, so I’m not complaining about that), then the
> first step in writing a new isNumber function is to define its purpose
> - what is it for? Next would be to define what a number is (which may
> seem trivial at first glance but the points discussed above show it
> isn't) and the context in which isNumber is or isn’t suitable. Is it
> to test that the value is type number? An instance of Number? A value
> that can safely be used in an arithmetic operation? One that can be
> converted to a useful number? And so on.
>
> Without knowing what the purpose of the function is, it’s impossible
> to say how it should handle edge cases. And if a purpose can’t be
> stated concisely, then perhaps it doesn’t have one that is useful.
I fully agree with you on this one : )
--
kangax
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---
