Native Objects .prototype extending

[wilq]

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

 

[Richard Cornford]

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.

 

[Dmitry A. Soshnikov]

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....hread/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

 

[Jorge]

(...) 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 ?

 

[Richard Cornford]

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.

 

[Jorge]

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 ?

 

[Richard Cornford]

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.

 

[wilq]

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