Objects for Number, String, Boolean, Date acts like their native counter part
Biju wrote:
[behaviour of wrappers] is weird...
Why cant we make objects for Number, String, Boolean, Date acts like their native counter part? That will be what an average web developer expecting. And I dont think it will make existing web break.
No, this brokenness is heavily relied on. It's not an obscure corner case.
Just don't use wrapper objects [*]. They are totally unnecessary and useless. If a fix is needed, it is to have the spec say that explicitly.
[*] except where they are generated implicitly as temporaries when a property of a primitive value is accessed -- although I bet most JS programmers don't even know that is happening.
On May 17, 2009, at 5:14 PM, David-Sarah Hopwood wrote:
Biju wrote:
[behaviour of wrappers] is weird...
Why cant we make objects for Number, String, Boolean, Date acts like their native counter part? That will be what an average web developer expecting. And I dont think it will make existing web break.
No, this brokenness is heavily relied on. It's not an obscure corner
case.
Indeed, some savvy JS hackers, coping with older implementations that
always wrap, create new String(big_string) explicitly, then call hot
methods on it in a loop, precisely in order to amortize the wrapper
overhead.
Just don't use wrapper objects [*]. They are totally unnecessary and useless. If a fix is needed, it is to have the spec say that
explicitly.
It would be great to get rid of implicit wrapping. It will take a
while. AFAICT people use wrappers for various reasons, even in new
code. The ES5 strict mode changes to avoid "coercing this" may help.
We'll see.
[*] except where they are generated implicitly as temporaries when a property of a primitive value is accessed -- although I bet most JS programmers don't even know that is happening.
This is optimized away by many implementations. It's not observable
provided the wrapper object can't be captured via |this| by a user-
defined function.