On Feb 9, 11:37 am, kangax <kan...@gmail.com> wrote:
> 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.
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.
[...]
> > > 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`)
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. :-)
> > > > 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.
And Prototype.js's implementation of "Class" also. What a tangled web
we weave. :-)
> > 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).
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.
>
>
> > > 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 : )
OT, but I'll mention it anyway: isNumber is used in up(). Given that
it is likely an expression will be used as a parameter and may return
anything, test the result of up('1') and up(NaN).
--
Rob
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
