je**********@gmail.com wrote:
http://htmatters.net/htm/1/2006/01/E...n-implicit.cfm
the ECMA-262 3rd edition standard is dated from 1999
so people comming with the argument that augmenting the prototype
might break a futur version of the language is kind of flawed
first, the next update of ECMA-262 will be ECMAScript 4
and that will occur around 2007
listen to this gillmore podcast with Brendan Eich (timestamp 00h55mn53sec)
http://gillmorgang.podshow.com/?p=25
(you have a slight surely full of errors transcript of the interview here
http://www.zwetan.com/blog/ECMAScrip...crapnotes.html )
second, even with ECMAScript 4 and its syntax ressembling class-based
langauge
you will still be able to augment the prototypes
(from experience with ActionScript 3, being very close to ECMAScript 4)
take an exemple with Firefox 1.5
this browser add some methods to the Array.prototype:
some, filter, forEach, etc...
these methodes are note defined in ECMA-262
1) you can rigthfully override them
2) if you don't override them, you can only use them
in the browser defining them, that means only Firefox 1.5, not the other
browsers
3) you can make your augmentation conditionnal
so Firefox 1.5 users can benefit from these new methods as native
implementation (much faster)
but having those methods accessible to other browsers
this is the problem of the smaller common denominator
do you want every browser (or other hosts) to be able to use those methods
or not ?
now about overriding methods already defined in ECMA-262
let's take for example in Object.prototype : isPrototypeOf,
memberIsEnumerable, hasOwnProperty
some Safari browsers even if claiming they implement the ECMA-262 standard
do not define those methods
then augmenting the prototype of Object object can allow you to "updgrade"
those browsers
you can also do it in a conditional way to not override other browsers
native implementation
this is _also_ the problem of the smaller common denominator
do you want every browser (or other hosts) to be able to use those standard
methods or not ?
The real problem about the pros and cons is about how do you design an
object oriented system
is it more logic for you to define a "trim" method in the String.prototype
or to use a global function "trim" ?
remember also than In OOP global variables are considered bad
http://c2.com/cgi/wiki?GlobalVariablesAreBad http://c2.com/cgi/wiki?GlobalVariablesConsideredHarmful
etc..
look at how these kind of methods are designed/implemented in other
languages framework as Java, .NET, etc.
the trim method is defined in the String type, not elsewhere
and that's the problem imho with ECMA-262,
it's defining basic core objects, but it's not defining a framework
that's it, ECMAScript is missing what you can call an application framework
the language is very small, very light..but with also a great feature
the language can patch and augment itself using prototype methods
on those same simple core objetcs.
just saying like that it is bad just because tons of people repeating it
like sheep
is a little too much easy imho, the ECMAScript language is made from the
start to be
dynamic, augmenting methods in the prototype can be seen as a very good
thing and a feature
instead of a bad thing to surely not do...
some pros:
one good reason to do that would be good naming
http://c2.com/cgi/wiki?MeaningfulName
another good reason would be to apply polymorphism on the core objects
http://c2.com/cgi/wiki/wiki?PolyMorphism
also in the goal to have a coherent object oriented system the following are
good reasons too
http://c2.com/cgi/wiki?OnceAndOnlyOnce http://c2.com/cgi/wiki?DontRepeatYourself
look again at the "trim" method and ask yourself some questions:
does it make sens to have this method in any other object than the String
object ?
do you trim Array or Boolean ?
is it logic for an user to apply the trim method to a String object ?
is the "trim" name a meaningfull name for the method ?
why will you do a "for..in" on a String object ?
do you or users using this method will gain time in their everyday
programming task ?
does it work everywhere you plan to use it ?
etc...
but the article is right on one point
"Just because you can, doesn't mean you should though"
you should surely not add anything to the prototype just because you can,
it must be done in a logical, well thought and usefull way.
are you just reacting to the article or do you ask all that because
you're thinking of adding some methods to the prototype and
because you heard a lot that "it is bad" you're not sure ?
zwetan