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. -- 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 email@example.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 -~----------~----~----~----~------~----~------~--~---