I have a DB Cache where i store the value in Number object, i want to
send back this value without to use valueOf each time.
And Hash.toQueryString() is a good example why it should detect Number
Object. I don't think that this function can ignore Number Object.
Cordially,
Alex
On 7 oct, 17:05,
POLS is a no-brainer here. Since this IS a legit line in javascript:
var n = new Number(4);
then saying:
Object.isNumber(n); = false
is ridiculous. Regardless of whether using new Number is preferred syntax
or not, its craziness to claim that that's a valid response for that
function.
-Jerod
why go throw all this complexity when javascript has a native isNaN function...
On Wed, Oct 8, 2008 at 6:40 PM, Tom Gregory [EMAIL PROTECTED] wrote:
Thanks for the reply.
I realize I don't get a vote here, but IMHO it either needs to be a)
well documented that Object.isNumber( new
I shall end the shitstorm here and now.
To quote the rhino book:
Once we've created a string object S [through `new String`], what can
we do with it? Nothing that we cannot do with the corresponding
primitive string value. If we use the `typeof` operator, it tells us
that S is indeed an object,
For the record, I can confirm that this issue breaks the
script.aculo.usAutocompleter with ie 6. The lighthouse patch fixes it,
at least in my case.
On Tue, Oct 7, 2008 at 11:37 AM, mona remlawi [EMAIL PROTECTED]wrote:
I got a the same error described in the following ticket when I added
a
On Oct 8, 2008, at 11:29 AM, Andrew Dupont wrote:
I shall end the shitstorm here and now.
... he probably can't think of a single case in which it's
_useful_ to use the wrapper objects instead of the primitives they
wrap.
Honestly, I can't either. I don't see any reason to use the
No, you were completely right — either it should support both the
primitive and the wrapper _or_ we need to document why it does not. I
was prepared to say we'd do the latter, since I didn't want to deal
with the differences between the two, but it turns out there _are_ no
differences, save for
