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. > > > 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. `isNumber` works in multi-frame environment. `instanceof`/ `constructor` don't: numberObjectFromOtherWindow instanceof Number; // false Object.isNumber(numberObjectFromOtherWindow); // true There are obviously other ways to accomplish this; say, first trigger "ToNumber" and then use `typeof`: typeof +numberObjectFromOtherWindow; // number but the point is that `isNumber` works "reliably" in multi-frame environment, while `instanceof` doesn't. > > 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? `instanceof` doesn't work across frames - there's not much we can do. I personally have almost never worked with frames (and always try to design them out of the application, as much as requirements allow :)) > > > 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`) > > > > 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. > > 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). > > > 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 : ) -- 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 -~----------~----~----~----~------~----~------~--~---