J
Jonas Raoni
(e-mail address removed) escreveu:
I think it's bad, but I use it sometimes... As the guy said, in the
future the language may add something that you've defined, and your
code will end up breaking the standard...
The only advantage I see is to "prettify" the code and also fix things
that are missing due to different versions, i mean: if(!o.x) o.x = ...
If you modify the prototype of Object or Array, it will damage the
"for..in" for example, so, by modifying the prototype you can face such
situation in the next js version
I think it's bad, but I use it sometimes... As the guy said, in the
future the language may add something that you've defined, and your
code will end up breaking the standard...
The only advantage I see is to "prettify" the code and also fix things
that are missing due to different versions, i mean: if(!o.x) o.x = ...
If you modify the prototype of Object or Array, it will damage the
"for..in" for example, so, by modifying the prototype you can face such
situation in the next js version
S
sharpfang
My vote: Extend (add methods), don't modify (override/overload
methods). Unless you have a strong reason to...
But your own method, on your page overrides the "updated" version, so
it all still works. And more important, whoever uses the "new improved"
version of JS, must provide an alternative to users using the old
version of JS. You don't. If you feel like it, change your function to
follow the new "standard", but that's not a must.
If you publish "javascript libraries" for the world to use, with your
extensions to function prototypes, you're responsible for all the cases
where it goes wrong. If you use it just in your page, you're
responsible for that page.
I personally was very fond of Array.prototype.contains( ) I made for my
own use and found it useful in several cases...
T
Thomas 'PointedEars' Lahn
http://htmatters.net/htm/1/2006/01/EIBTI-for-Javascript-explicit-is-better-than-implicit.cfm
While the recommendation is sound, ISTM that the rationale is not
well-founded. If a future language version or another implementation
would implement a method, augmenting the constructor or prototype
object would most certainly overwrite that method (because we assume a
conforming ECMAScript implementation and we are not talking about host
objects), so there would be no problem with the order of arguments, for
example.
A problem would only arise if the prototype was augmented conditionally,
and the article rightfully questions that approach. Another drawback of
augmentation is that if a future language version or another implementation
would implement that method as augmented, augmenting unconditionally would
probably result in a less efficient implementation of the respective
feature.
PointedEars
While the recommendation is sound, ISTM that the rationale is not
well-founded. If a future language version or another implementation
would implement a method, augmenting the constructor or prototype
object would most certainly overwrite that method (because we assume a
conforming ECMAScript implementation and we are not talking about host
objects), so there would be no problem with the order of arguments, for
example.
A problem would only arise if the prototype was augmented conditionally,
and the article rightfully questions that approach. Another drawback of
augmentation is that if a future language version or another implementation
would implement that method as augmented, augmenting unconditionally would
probably result in a less efficient implementation of the respective
feature.
PointedEars
Z
zwetan
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/ECMAScript/Gillmor_Gang_with_Brendan_Eich_scrapnotes.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