Math ugliness.
in [JavaScript]
|
From: Dmitry A. Soshnikov on 17 Feb 2010 04:15 On Feb 17, 2:23 am, Jorge <jo...(a)jorgechamorro.com> wrote: > Hi, > > Do you think -as I do- that the Math object is an ugly artifact ? > Well, here's a nice way of getting rid of it : > Artifact of not - that's questionable, because some methods fit to numbers (e.g. .round(), other), some by semantic - for mathematical actions and could be placed in separate Math'ematical module. Other question is style of code. I always don't like to repeat some chunks of code, I always try to decrease such repetitions. That's why I really don't like new approach in ES5 for methods to work with objects which are placed not in `Object.prototype' letting to work in OOP-style, but in `Object' constructor itself. I know the reasons why it was done so (such a "protection" if simple object will have own such property), but that seems to my ugly too (just an abstract example): var o = Object.freeze( Object.seel( Object.defineProperties( Object.create(proto), properties ) ) ); This repetition of Object.-Object.-Object. is really `heavy'. The first thing which also can be done in ES5 (to make it more comfortable in some viewpoint) - is definition of the same methods in `Object.prototype' (with [[Enumerable]] = false), allowing elegant chains, decreasing of the repeated chunks of code such as `Object.': var o = Object.create(proto) .defineProperties(properties) .seel() .freeze(); By the way, e.g. in Ruby, many of this methods (and for numbers and for objects) are instance methods: 1.5.round() {'a' => 10}.freeze() and so on. /ds
From: Jorge on 17 Feb 2010 04:22 On Feb 17, 10:15 am, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > > By the way, e.g. in Ruby, many of this methods (and for numbers and > for objects) are instance methods: > > 1.5.round() > {'a' => 10}.freeze() > > and so on. That's the way it ought to be, imo, and JS is powerful enough that allows for sculpting it at your liking. -- Jorge.
From: Richard Cornford on 17 Feb 2010 04:33 RobG wrote: > On Feb 17, 9:23 am, Jorge wrote: >> Do you think -as I do- that the Math object is an ugly >> artifact ? Well, here's a nice way of getting rid of it : >> >> Number.prototype.sin= function () { return Math.sin(+this); }; > I'm curious about the use of unary +. Presumably the identifier > is resolved to a number primitive in the first place, otherwise > x.sin wouldn't resolve to Number.prototype.sin. > > Or have I missed something? <snip> In ES3 the - this - keyword always refers to an object, so you are guaranteed that it is never a primitive value. And having - x.sin - resolve as - Number.prototype.sin - pre-supposes that - x - is type converted into a Number object during the resolution of the property accessor, as only objects can have methods/properties. This means that code like:- 2..pow(10).sqrt() - implies two numeric primitive to Number object type-conversations (and two Number object to numeric primitive type conversations somewhere inside the methods). Richard.
From: Jorge on 17 Feb 2010 04:39 On Feb 17, 10:33 am, "Richard Cornford" <Rich...(a)litotes.demon.co.uk> wrote: > > - implies two numeric primitive to Number object type-conversations One sometimes has to wonder what's really going on inside one's browser... "primitive" "conversations" ? LOL. -- Jorge.
From: Jorge on 17 Feb 2010 05:08
On Feb 17, 10:15 am, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > On Feb 17, 2:23 am, Jorge <jo...(a)jorgechamorro.com> wrote: > > > Hi, > > > Do you think -as I do- that the Math object is an ugly artifact ? > > Well, here's a nice way of getting rid of it : > > Artifact of not - that's questionable, because some methods fit to > numbers (e.g. .round(), other), some by semantic - for mathematical > actions and could be placed in separate Math'ematical module. Why the hell given that numbers are objects too, can't they have their own methods in their own prototype ? Why if not to copy Java style were they moved into a separate "Math" object ? In order to make it an "optional" object (as Crockford states in that video #2) for lesser ES implementations ? -- Jorge. |