Christophe Porteneuve wrote:
> Hello Fred,
>
> Fred a écrit :
[...]
> > If you are using multiple libraries, you should have a strong
> > preference for those that don't modify built-in objects.
>
> This, again, is debatable.
Hence this debate. :-)
> Here's my POV: the only reason prototype
> extension (as long as it doesn't break behavior of the prototype's
> standard properties) might be a problem is for/in loops, AFAIK.
Also where two libraries add a property with the same name to the same
object's prototype chain - json.js stomps (quite deliberately) on the
toString() method of all built-in objects. The concept of namespaces
has been implemented by many libraries to ensure they have a minimal
footprint.
> On the
> other hand, prototype extension is, admittedly, key to leveraging the
> power of JS. That's what prototypes are *for*. Most of the really
> powerful libraries out there rely on prototype extension, which makes
> for faster, more concise code than vanilla procedural code.
The discussion here is not about modifying prototypes in general (if
that were a problem the answer is "don't use a prototype based
language") but about libraries (or "frameworks" to be hip) extending
the prototypes of built-in objects.
> > I think you have that backwards - libraries that modify built-in
> > objects don't play well with code that expects those objects to be
> > unadulterated.
>
> See? POV :-) If built-in objects were not supposed to be extended,
> they wouldn't have accessible prototypes.
The issue is using a *library* that extends built-in objects, not
extending object prototypes in general. Prototype.js has already been
modified (as far as I know) to not extend Object based (I guess) on
feedback from users ("users" being developers using Prototype.js).
One could argue that JavaScript was intended to be a small, simple
language. The fact that there is no mechanism to add non-enumerable
properties could be seen as encouragement not to extend built-in
objects, and encouragement to provide customised objects within a
namespace rather than a global context.
> Same goes for DOM objects
> (but this outside of standard JS scope, it's more of a browser maker's
> choice).
The results of extending DOM objects is browser-dependent. The
ECMAScript Language specification essentially says "host objects can do
what they like", which is just as well given the wide variety of host
platforms (other than browsers) on which it is implemented.
In regard to the W3C's DOM, its specifications are not necessarily
peculiar to javacscript. They are intended to describe interfaces that
can be implemented in any language, and should represent a common set
of functionality - it should not attempt to be the bleeding edge.
[...]
> However, the whole reason for this discussion is the for/in loop, which
> is used here mostly as syntactic sugar for array loops, a usage that is
> definitely *not* its primary purpose.
It is a direct consequence of Array being an extension of Object. An
alternative view is that Array should have all the properties (either
inferred or explit) of Object, in addition to those provided by
Array.prototype.
--
Fred
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
