Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Math ugliness.

Reply
Thread Tools

Math ugliness.

 
 
Jorge
Guest
Posts: n/a
 
      02-17-2010
On Feb 17, 1:22*pm, Richard Cornford <(E-Mail Removed)>
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.
 
Reply With Quote
 
 
 
 
Jorge
Guest
Posts: n/a
 
      02-17-2010
On Feb 17, 1:58*pm, Thomas 'PointedEars' Lahn <(E-Mail Removed)>
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.
 
Reply With Quote
 
 
 
 
Richard Cornford
Guest
Posts: n/a
 
      02-17-2010
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.
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      02-17-2010
On Feb 17, 6:54*pm, Richard Cornford <(E-Mail Removed)>
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.
 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      02-17-2010
On Feb 17, 6:05 pm, Jorge wrote:
<snip>
> But you'll admit that this -ES3 behaviour- is not what one
> would -for many reasons- expect:


Generally the handling of - this - in ES3 is found unexpected/
unintuitive by many people.

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


No. In an environment where the - this - value is always an object,
type-conversion from primitive for property accessors create objects
internally and temporarily during evaluation, and objects are only
equal if they share identity the expected result is the one observed.

And for someone who doesn't understand the language they are writing
having any expectations is unrealistic.

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

>
> Are you sure ?


Earlier in this thread, didn't Thomas go to a great deal of effort to
show that in ES5 it is possible for - this - values to be numeric
primitives regardless of the mode?

Richard.
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      02-17-2010
On Feb 17, 7:45*pm, Richard Cornford <(E-Mail Removed)>
wrote:
> On Feb 17, 6:05 pm, Jorge wrote:
> <snip>
>
> > But you'll admit that this -ES3 behaviour- is not what one
> > would -for many reasons- expect:

>
> Generally the handling of - this - in ES3 is found unexpected/
> unintuitive by many people.
>
> > var x= 3;
> > Number.prototype.test= function () { return this; };
> > x.test() === x.test()
> > --> false

>
> > Yes ?

>
> No. In an environment where the - this - value is always an object,
> type-conversion from primitive for property accessors create objects
> internally and temporarily during evaluation, and objects are only
> equal if they share identity the expected result is the one observed.


It's totally unexpected because the left hand x is exactly the same x
as the right hand x. It's only expected behaviour after 1st scratching
your head for a -presumably long- while and 2nd having read the
related chapter of the ES3 spec. But -I guess- this won't happen
anymore in ES5: the wrapper object will be used just to lookup the
property in the appropriate .proto chain, but won't be passed on to
"this".
--
Jorge.
 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      02-17-2010
On Feb 17, 7:00 pm, Jorge wrote:
> On Feb 17, 7:45 pm, Richard Cornford wrote:
>> On Feb 17, 6:05 pm, Jorge wrote:
>> <snip>

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

>
>> Generally the handling of - this - in ES3 is found unexpected/
>> unintuitive by many people.

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

>
>>> Yes ?

>
>> No. In an environment where the - this - value is always an
>> object, type-conversion from primitive for property accessors
>> create objects internally and temporarily during evaluation,
>> and objects are only equal if they share identity the expected
>> result is the one observed.

>
> It's totally unexpected because the left hand x is exactly the
> same x as the right hand x.


Only in as far as:-

var x = 3;
x.something = 'something';

alert(x.something); //outputs undefined.

- is unexpected because you write to and then read from the same x.
Changing the way that the - this - value works does not 'solve'
implicit type-conversion confusions.

> It's only expected behaviour after 1st scratching
> your head for a -presumably long- while


That sounds like a waste.

> and 2nd having read the
> related chapter of the ES3 spec.


Any decent book on the subject should have made the point. It is a
pity that there are so few decent books on the subject but the good
ones should explain the aspects of the language that people find
difficult to understand.

> But -I guess- this won't happen anymore in ES5: the wrapper
> object will be used just to lookup the property in the
> appropriate .proto chain, but won't be passed on to "this".


Hence the incompatibility with ES3.

Richard.
 
Reply With Quote
 
Dmitry A. Soshnikov
Guest
Posts: n/a
 
      02-17-2010
On Feb 17, 10:58*pm, kangax <(E-Mail Removed)> wrote:

[...]

>
> some of ES5 bits are already implemented in, for example, nightly
> WebKit (and Opera 10.50 alpha, IIRC).
>


Also if interested, almost all features of ES5 (except of "strict
mode") are implemented in Rhino 1_7R3pre: <URL: ftp://ftp.mozilla.org/pub/mozilla.org/js/>.
I use it for test - as in sources there's a runnable js-console.

/ds
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      02-17-2010
Richard Cornford 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.


Yes, there is: Repeated accesses to properties of `this' would not need
repeated conversion to object, whether inside the method context or outside
(if `this' was returned and the return value re-used).


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
 
Reply With Quote
 
Peter Michaux
Guest
Posts: n/a
 
      02-17-2010
On Feb 16, 3:23 pm, Jorge <(E-Mail Removed)> wrote:
> Hi,
>
> Do you think -as I do- that the Math object is an ugly artifact ?


No.

Think of it as a namespace for Math functions.

> (2).pow(10)
> --> 1024


That is a perfect example of where message passing for (at least) Math
fails. The exponentiation function takes two arguments: base and
exponent. Neither is more important than the other. Neither is the
object to which I wish to send a message. Neither argument has state
that is or needs mutation. They are just arguments to a pure function
that has no side effects. Message passing is an inappropriate paradigm
for this sort of computation.

This looks a whole lot better:

pow(2, 10)

Adding a namespace is not significantly different:

Math.pow(2, 10)

Peter
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Math.random() and Math.round(Math.random()) and Math.floor(Math.random()*2) VK Javascript 15 05-02-2010 03:43 PM
Math.min and Math.max for byte / short Philipp Java 9 07-23-2008 12:37 AM
math.h trig functions questions (and some forgotten high school math) Mark Healey C Programming 7 05-22-2006 10:42 AM
Re: Is still math.h the C++ math library ? AciD_X C++ 4 04-01-2004 07:29 PM
Why can I not use: Math a=new Math(); chirs Java 18 03-02-2004 06:00 PM



Advertisments