On Feb 8, 9:59 pm, RobG <rg...@iinet.net.au> wrote: > On Feb 9, 11:37 am, kangax <kan...@gmail.com> 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 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 -~----------~----~----~----~------~----~------~--~---