Math ugliness.
in [JavaScript]
|
From: Thomas 'PointedEars' Lahn on 17 Feb 2010 07:58 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 17 Feb 2010 11:14 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 17 Feb 2010 11:18 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 17 Feb 2010 12:54 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 17 Feb 2010 13:05
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. |