From: Thomas 'PointedEars' Lahn on
Jake Jarvis wrote:

> On 17.02.2010 09:36, wrote Jorge:
>> Thomas 'PointedEars' Lahn wrote:
>>> (...) In fact, this idea is anything but original. (...)
>>
>> And then came Pointy, decided to spoil the fun... :-)
>>
>> I've never seen it before.. who, where, when ? Have you got any urls,
>> plz ? [...]
>
> http://www.prototypejs.org

The idea of augmenting built-in prototypes, particularly Number.prototype,
is much, much older than that. It dates back to at least 2001 CE. Google
is your friend. [psf 6.1]


PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Jorge on
On Feb 17, 1:22 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk>
wrote:
>
> You may recall that Google Chrome had been observed to be getting this
> aspect of ES3 wrong (with regard to String object methods in those
> cases) long before there was an ES5 (or this change had been
> proposed), so for at least one of the participants in the ECMA
> committee getting the change passed meant not having to fix what had
> previously been a faulty script engine.

Leaving aside compatibility with ES3, is there any benefit in forcing
"this" to be an object ?
Because I see at least an advantage in not forcing it: that "this" can
be undefined.
--
Jorge.
From: Jorge on
On Feb 17, 1:58 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Jake Jarvis wrote:
> >http://www.prototypejs.org
>
> The idea of augmenting built-in prototypes, particularly Number.prototype,
> is much, much older than that.  It dates back to at least 2001 CE.  Google
> is your friend. [psf 6.1]

And the idea of putting Math's methods where they belong dates back to
at least... ¿?
--
Jorge.
From: Richard Cornford on
On Feb 17, 4:14 pm, Jorge wrote:
> On Feb 17, 1:22 pm, Richard Cornford wrote:
>> You may recall that Google Chrome had been observed to be
>> getting this aspect of ES3 wrong (with regard to String
>> object methods in those cases) long before there was an
>> ES5 (or this change had been proposed), so for at least
>> one of the participants in the ECMA committee getting the
>> change passed meant not having to fix what had previously
>> been a faulty script engine.
>
> Leaving aside compatibility with ES3, is there any benefit
> in forcing "this" to be an object ?

None.

> Because I see at least an advantage in not forcing it: that
> "this" can be undefined.

Compatibility is the issue. For years it has been a well known and
absolute fact that in javascript - this - _always_ refers to an
object. That means that for many years people will have been writing
code that relies on the truth of that fact. This code is now likely to
be exposed to environments where - this - is no longer guaranteed to
be an object, and if it has acted on the assumption that - this - will
be it will error whenever - this - is null or undefined. And it was
finding that - this - values were string primitives when they should
have been string objects that exposed the fault in Google Chrome. If
these things weren't important then that would not have been being
reported within a couple of months of Chrome being released.

And we are not looking at a voluntary opt-in here, this is not 'strict
mode' only.

Richard.
From: Jorge on
On Feb 17, 6:54 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk>
wrote:
> On Feb 17, 4:14 pm, Jorge wrote:
>
> > On Feb 17, 1:22 pm, Richard Cornford  wrote:
> >> You may recall that Google Chrome had been observed to be
> >> getting this aspect of ES3 wrong (with regard to String
> >> object methods in those cases) long before there was an
> >> ES5 (or this change had been proposed), so for at least
> >> one of the participants in the ECMA committee getting the
> >> change passed meant not having to fix what had previously
> >> been a faulty script engine.
>
> > Leaving aside compatibility with ES3, is there any benefit
> > in forcing "this" to be an object ?
>
> None.
>
> > Because I see at least an advantage in not forcing it: that
> > "this" can be undefined.
>
> Compatibility is the issue. For years it has been a well known and
> absolute fact that in javascript - this - _always_ refers to an
> object. That means that for many years people will have been writing
> code that relies on the truth of that fact. This code is now likely to
> be exposed to environments where - this - is no longer guaranteed to
> be an object, and if it has acted on the assumption that - this - will
> be it will error whenever - this - is null or undefined. And it was
> finding that - this - values were string primitives when they should
> have been string objects that exposed the fault in Google Chrome. If
> these things weren't important then that would not have been being
> reported within a couple of months of Chrome being released.

But you'll admit that this -ES3 behaviour- is not what one would -for
many reasons- expect:

var x= 3;
Number.prototype.test= function () { return this; };
x.test() === x.test()
--> false

Yes ?

> And we are not looking at a voluntary opt-in here, this is not 'strict
> mode' only.

Are you sure ?
--
Jorge.