Native Objects .prototype extending

Discussion in 'Javascript' started by wilq, Nov 27, 2009.

  1. wilq

    wilq Guest

    Hello Experts,

    I got a question for you, that bothers me for some time. I already
    heard many times that extending a Native Objects (like Array,
    Function, etc.) prototype is not a good idea (like the prototype lib
    does). But when I try to find good reason for that I could not find
    too many... I also tried to find this information here on google
    groups, but with no success, so sorry If I ask for something obvious
    for you. Would you be so kind and create a list of Pros and Cons of
    extending Native Objects? I also would like to be Objective (not
    subjective) so please don't say that generally idea is bad because
    extending Object.prototype might broke normal usage of syntax like
    "for (var..in..)" - you simply can not extend object, but still this
    does not apply for a functions extending (unless you use for..in.. on
    function objects). I heard that someone says that its bad from
    performance side - is that true ? Whatever you get in mind please
    share !

    Thanks in advance for any responses here,
    Cheers,
    Wilq32
     
    wilq, Nov 27, 2009
    #1
    1. Advertising

  2. On Nov 27, 1:08 pm, wilq wrote:
    > Hello Experts,


    Who?

    > I got a question for you, that bothers me for some time. I already
    > heard many times that extending a Native Objects (like Array,
    > Function, etc.) prototype is not a good idea (like the prototype lib
    > does). But when I try to find good reason for that I could not find
    > too many... I also tried to find this information here on google
    > groups, but with no success, so sorry If I ask for something obvious
    > for you. Would you be so kind and create a list of Pros and Cons of
    > extending Native Objects? I also would like to be Objective (not
    > subjective) so please don't say that generally idea is bad because
    > extending Object.prototype might broke normal usage of syntax


    Syntax? The syntax is irrelevant, it is the process that matters here.

    > like "for (var..in..)" - you simply can not extend object, but
    > still this
    > does not apply for a functions extending
    > (unless you use for..in.. on function objects).


    This is what makes the general statement far too broad. I don't recall
    ever seeing anyone doing for-in on a function (except accidentally),
    and it is pretty unusual to see anyone creating any of the String,
    Number or Boolean objects so doing for-in on those should be less
    common.

    Personally, I would not be at all concerned about extending the
    prototypes of Function, Number, String or Boolean. I haven't tended to
    do that myself but I would not worry about it if I did see some reason
    for doing so.

    Probably the main 'pro' for extending prototypes would be convenience;
    the convenience of calling methods on primitive values, where are
    prototype defined - trim - method for strings would be an ideal
    example.

    The only real 'con' of extending prototypes is the - for-in - issue,
    and it only applies if you either know that you will be doing for-in
    on (significant type of) objects, or if you are intending to expose
    the code to environment that are not 100% known in advance. So it is
    an issue for the writers of libraries, and authors writing things for
    inclusion in other people's pages, or the authors of pages that
    include things from third parties.

    The web application I work on most of the time uses for-in on some
    very sparse arrays, and they do that for performance reasons, which
    makes filtering within the for-in loops to verify that the enumerated
    properties are not inherited counterproductive. The result is that the
    first page of the developers' documentation for the application states
    that nobody is _ever_ allowed to extend/modify the Array prototype.
    That injunction is there because in that context it is known to be
    necessary, but no arbitrary restrictions have been placed on other
    prototypes.

    > I heard that
    > someone says that its bad from performance side - is that true ?


    Generally no, but performance varies quite a bit from environment to
    environment, and many specific optimisations might impact here. On the
    other hand, the question of performance cannot even be addresses until
    you know what you are comparing with which alternative.

    > Whatever you get in mind please share !

    <snip>

    Be careful what you wish for ... .

    Richard.
     
    Richard Cornford, Nov 27, 2009
    #2
    1. Advertising

  3. On Nov 27, 4:08 pm, wilq <> wrote:
    > Hello Experts,
    >


    [...]

    > I also tried to find this information here on google
    > groups, but with no success, so sorry If I ask for something obvious
    > for you.
    >


    Seems, that was you who created that thread: <URL:
    http://groups.google.ru/group/comp.lang.javascript/browse_thread/thread/3a165e79d47fd347/8c5e17f2d8aba4cc?hl=en>

    There where explanations also.

    Shortly:

    - until we haven't control of {DontEnum} it's a bad idea to augmenting
    Object.prototype, 'cause everything (except some host objects are
    inherit from it);

    - using several 3rd-party libraries can make name conflicts, so in
    this case the good documentation should be.

    In all other cases - it, IMO, absolutely normal idea (if you're
    talking about own project) to augment native prototypes, 'cause it's
    in ideology of such dynamic languages. If some person strongly
    recommend to not do that, will be better if he'll recommend to use
    some static language.

    Some uses own namespace for this purpose, but again ideologically it
    better and clearer to write in OOP style such as `string.capitalize()`
    than that long `Ext.util.Format.capitalize(string)` written in
    procedural-style.

    About performance, `for...in` for arrays should be slower as analyzing
    prototype chain (thought, for some sparse we can get prototype chain
    analysis and via indexing for-loop - `for... k < length; k++`).

    So, this is not a bad idea. Always check and think yourself, don't
    simply agree just with "authority" meaning which statements that this
    a bad idea.

    /ds
     
    Dmitry A. Soshnikov, Nov 27, 2009
    #3
  4. wilq

    Jorge Guest

    On Nov 27, 3:02 pm, Richard Cornford <>
    wrote:
    > (...) The result is that the
    > first page of the developers' documentation for the application states
    > that nobody is _ever_ allowed to extend/modify the Array prototype.
    > That injunction is there because in that context it is known to be
    > necessary, but no arbitrary restrictions have been placed on other
    > prototypes. (...)


    Not allowed to extend Array.prototype but can extend Object.protoype ?
    --
    Jorge.
     
    Jorge, Nov 27, 2009
    #4
  5. On Nov 27, 2:21 pm, Jorge wrote:
    > On Nov 27, 3:02 pm, Richard Cornford wrote:
    >
    >> (...) The result is that the first page of the developers'
    >> documentation for the application states that nobody is
    >> _ever_ allowed to extend/modify the Array prototype. That
    >> injunction is there because in that context it is known
    >> to be necessary, but no arbitrary restrictions have been
    >> placed on other prototypes. (...)

    >
    > Not allowed to extend Array.prototype but can extend
    > Object.protoype ?


    If the environment is know not to contain any (non-filters)
    applications of for-in to ordinary objects what would be wrong with
    that?

    Richard.
     
    Richard Cornford, Nov 27, 2009
    #5
  6. wilq

    Jorge Guest

    On Nov 27, 3:45 pm, Richard Cornford <>
    wrote:
    > On Nov 27, 2:21 pm, Jorge wrote:
    >
    > > On Nov 27, 3:02 pm, Richard Cornford wrote:

    >
    > >> (...) The result is that the first page of the developers'
    > >> documentation for the application states that nobody is
    > >> _ever_ allowed to extend/modify the Array prototype. That
    > >> injunction is there because in that context it is known
    > >> to be necessary, but no arbitrary restrictions have been
    > >> placed on other prototypes. (...)

    >
    > > Not allowed to extend Array.prototype but can extend
    > > Object.protoype ?

    >
    > If the environment is know not to contain any (non-filters)
    > applications of for-in to ordinary objects what would be wrong with
    > that?


    That [] instances inherit from Object.prototype too and you're not
    filtering for..ins in [] instances ?
    --
    Jorge.
     
    Jorge, Nov 27, 2009
    #6
  7. On Nov 27, 3:24 pm, Jorge wrote:
    > On Nov 27, 3:45 pm, Richard Cornford wrote:
    >> On Nov 27, 2:21 pm, Jorge wrote:
    >>> On Nov 27, 3:02 pm, Richard Cornford wrote:
    >>>> (...) The result is that the first page of the developers'
    >>>> documentation for the application states that nobody is
    >>>> _ever_ allowed to extend/modify the Array prototype. That
    >>>> injunction is there because in that context it is known
    >>>> to be necessary, but no arbitrary restrictions have been
    >>>> placed on other prototypes. (...)

    >
    >> > Not allowed to extend Array.prototype but can extend
    >> > Object.protoype ?

    >
    >> If the environment is know not to contain any (non-filters)
    >> applications of for-in to ordinary objects what would be wrong
    >> with that?

    >
    > That [] instances inherit from Object.prototype too and you're not
    > filtering for..ins in [] instances ?


    Yes, that is a good point.

    Richard.
     
    Richard Cornford, Nov 27, 2009
    #7
  8. wilq

    wilq Guest

    I warmly thank you for sharing your wisdom :)

    To be honest I got the same feeling about this subject, but I wanted
    to make sure that I did not forget about something... Thanks again for
    your time spent writing answer !

    Cheers,
    wilq32
     
    wilq, Nov 29, 2009
    #8
    1. Advertising

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. June Lee
    Replies:
    2
    Views:
    843
    Jim Cobban
    Apr 13, 2008
  2. Replies:
    13
    Views:
    231
    Richard Cornford
    Apr 8, 2006
  3. Replies:
    9
    Views:
    230
    Thomas 'PointedEars' Lahn
    May 26, 2006
  4. Replies:
    3
    Views:
    287
  5. javascript fish
    Replies:
    0
    Views:
    194
    javascript fish
    Oct 11, 2008
Loading...

Share This Page