Prev: javascript (ecmascript) libraries
Next: Runtime Instance Name without using eval()
From: wilq on 27 Nov 2009 08:08
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
From: Richard Cornford on 27 Nov 2009 09:02
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.
From: Jorge on 27 Nov 2009 09:21
On Nov 27, 3:02 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk>
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.
From: Richard Cornford on 27 Nov 2009 09:45
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.
From: Jorge on 27 Nov 2009 10:24
On Nov 27, 3:45 pm, Richard Cornford <Rich...(a)litotes.demon.co.uk>
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.
 |  Next  |  Last
Pages: 1 2
Prev: javascript (ecmascript) libraries
Next: Runtime Instance Name without using eval()