On Feb 8, 11:53 pm, kangax <kan...@gmail.com> wrote:
> On Feb 8, 8:19 am, RobG <rg...@iinet.net.au> wrote:
> [...]
> > It can hardly be called a bug when it does what the documentation says
> > it does (I think "works as designed" is the polite response).  The
> > function itself is a bit pointless though, as are similar functions
> > like isNumber, e.g.
> 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.

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

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?

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

> >   Object.isNumber(NaN); // true
> Should it return `false`?

According to the documentation, no - but the function name suggests
otherwise.  Perhaps ‘isNumberType’ more accurately reflects what the
function does.

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?

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

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

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 
For more options, visit this group at 

Reply via email to