Modifying String.prototype: pro or con?

Discussion in 'Javascript' started by, Jan 6, 2006.

  1. Guest

    1. Advertisements

  2. Jonas Raoni Guest


    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 example, so, by modifying the prototype you can face such
    situation in the next js version :)

    Jonas Raoni Soares Silva
    Jonas Raoni, Jan 6, 2006
    1. Advertisements

  3. Guest


    My vote: Extend (add methods), don't modify (override/overload
    methods). Unless you have a strong reason to...

    > Just because you can, doesn't mean you should though. For instance, a method you
    > add to String's prototype might require two arguments, but a future update to the
    > language itself might add the very same method with the arguments reversed.

    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...
    , Jan 6, 2006
  4. wrote:


    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

    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

    Thomas 'PointedEars' Lahn, Jan 6, 2006
  5. zwetan Guest


    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)
    (you have a slight surely full of errors transcript of the interview here )

    second, even with ECMAScript 4 and its syntax ressembling class-based
    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
    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

    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

    another good reason would be to apply polymorphism on the core objects

    also in the goal to have a coherent object oriented system the following are
    good reasons too

    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 "" 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 ?

    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, Jan 8, 2006
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Liber
    Sep 6, 2004
  2. Larry Webb
    Bob Long
    Jun 8, 2004
  3. Replies:
  4. June Lee
    Jim Cobban
    Apr 13, 2008
  5. Wayne Erfling
    Wayne Erfling
    Nov 18, 2006
  6. Matteo Mancini

    Piccolo con problema con il tipo float

    Matteo Mancini, Oct 8, 2007, in forum: Ruby
    Jano Svitok
    Oct 8, 2007
  7. Alexis Nikichine

    Modifying prototype chain

    Alexis Nikichine, Mar 21, 2005, in forum: Javascript
    Alexis Nikichine
    Mar 21, 2005
  8. Replies:
    Thomas 'PointedEars' Lahn
    May 26, 2006