On Feb 8, 9:59 pm, RobG <[email protected]> wrote:
> On Feb 9, 11:37 am, kangax <[email protected]> wrote:
[...]
> > 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.
>
> Not at all, it's what I was asking for. I can't conceive of a
> situation where I would use isNumber (either in its current state or
> the proposed modification). I'm asking for a scenario where I would
> *use* it.
I can't think of such scenario. I personally never use primitive
wrappers explicitly (language does a pretty good job at wrapping
primitives for me :))
[...]
> > `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`)
>
> Now you are back on topic. But [[Class]] can only be indirectly read
> via toString, so it isn't that reliable but might be good enough for
> most. Anything that has a [[Class]] of Number should probably emulate
> the properties of a native Number. The argument now goes to the same
> place as isArray - no need to repeat that here. :-)
Getting [[Class]] is actually very much reliable (and is clearly
documented in specs). I wrote a post about it some time ago [1]. The
only downside is host objects, which are obviously permitted to have
any [[Class]] value, including one of the native ones - "Array",
"Function", "Number", etc. IIRC, ES commitee is currently discussing
this as well (Restrictions of [[Class]] values in context of host
objects).
[...]
> Given that in version 1.6.0.3 (the current version as far as I know)
> it is:
>
> isNumber: function(object) {
> return typeof object == "number";
> },
>
> the documentation is correct. Perhaps you meant change the
> documentation when the new version is published.
Yes, we need to change it once the next release (current trunk) comes
out.
[...]
[1]
http://thinkweb2.com/projects/prototype/instanceof-considered-harmful-or-how-to-write-a-robust-isarray/
--
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~----------~----~----~----~------~----~------~--~---
