Rails spinoffs - Feb 2008 - Danger Will Robinson...DOM and JavaScript object extension using Prototype...help, Prototype...

I''ve found that one of the biggest arguments against Prototype and
similar frameworks/libraries is the potential pitfalls of extending
core and client-side JavaScript.  One component of this argument is
the "risk" of name collisions or different programmers overwriting
each other''s custom extensions.

I really like Prototype, but I have felt the consequences of the
"risky business" of extending DOM and JavaScript objects.  I just
spent the better part of two days debugging the unexpected behavior of
a third-party calandar script only to realize that one of my Date
object extensions was overwriting one of the extensions of the third-
party calendar script.

So, unless I exercise almost-obsessive caution, I stand a good chance
of overwriting one of Prototype''s extensions, a third-party script
stands a good chance of overwriting my extensions or Prototype''s
extensions, and I stand a good chance of overwriting the extensions of
a third-party script.  This makes incorporating JavaScript from a
variety of sources a unique challenge, and supports the argument that
Prototype doesn''t play well with other scripts.  Now, I''ll
agree that
many of these other scripts are poorly written, but still I''m
optimistic that we can still "all get along" a lot better than we do
now.

SO...I was wondering if there are any plans to provide a mechanism in
Prototype to help detect or prevent accidental overwriting of DOM and
JavaScript object extensions.  It seems like it would save a great
deal of debugging time and frustration if Prototype''s
Element.addMethods() and Object.extend() both threw a JavaScript error
when trying to add an extension on a DOM or JavaScript object that
already exists.

I find, when I''m working with multiple third-party scripts, I often
encounter accidental extension overwrites which are almost always
difficult to identify and debug.  In most cases, rather than throwing
a JavaScript error, the overwrites cause unexpected behavior.  So,
it''s often not clear if the script itself is the problem or if some
type of accidental overwrite has occurred.

Can or will Prototype come to the rescue?

I can understand that Prototype may be limited when it comes to the
actions of third-party scripts that extend the the DOM and JavaScript
objects without using Prototype, but it would still be a huge
improvement if Prototype just provided some built-in mechanisms to
programmers so we know when we''re overwriting other extensions that
were also added using Prototype.  However, at least for the JavaScript
object (string, date, etc), it seems like it would be possible to know
even if the extensions were not added using Prototype.
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

On Feb 18, 10:53 am, broberts
<brobert...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I''ve found that one of the biggest arguments against Prototype and
> similar frameworks/libraries is the potential pitfalls of extending
> core and client-side JavaScript.  One component of this argument is
> the "risk" of name collisions or different programmers
overwriting
> each other''s custom extensions.
We acknowledge this risk; if it''s the sort of thing you''re
worried
about, it''s a valid reason to choose another library.

In Ruby, runtime augmentation of built-in classes is both permitted
and encouraged. There are those who call Ruby developers rubes for
working in an environment where this sort of "monkeypatching" takes
place, but somehow it all works out without the sky falling or the
polar icecaps melting.

In JavaScript, of course, it''s a bit different. The language itself
gives us fewer tools to manage the potential pitfalls of a
heterogeneous scripting environment. We make the trade-off anyway,
since we think the benefits outweigh the costs. But, yeah, the costs
still piss me off.
> SO...I was wondering if there are any plans to provide a mechanism in
> Prototype to help detect or prevent accidental overwriting of DOM and
> JavaScript object extensions.  It seems like it would save a great
> deal of debugging time and frustration if Prototype''s
> Element.addMethods() and Object.extend() both threw a JavaScript error
> when trying to add an extension on a DOM or JavaScript object that
> already exists.
I can''t say we''ve got plans to do so, but it''d be
easy enough to write
your own version of Object.extend that would ensure the properties
you''re copying over don''t already exist:

Object.extendSafely = function(destination, source) {
  var keys = Object.keys(destination);
  for (var i in source) {
    if (keys.include(i))
      throw "Collision: " + i + " already exists";
  }
  return Object.extend(destination, source);
};

This wouldn''t help if two third-party scripts are colliding with each
other, but it would help if a third-party script is colliding with
code you wrote yourself.
> I find, when I''m working with multiple third-party scripts, I
often
> encounter accidental extension overwrites which are almost always
> difficult to identify and debug.  In most cases, rather than throwing
> a JavaScript error, the overwrites cause unexpected behavior.  So,
> it''s often not clear if the script itself is the problem or if
some
> type of accidental overwrite has occurred.
>
> Can or will Prototype come to the rescue?
I''m the first to admit we need to do better in cultivating a third-
party ecosystem for Prototype. Perhaps the first step is to assemble
some ad-hoc best practices for Prototype add-on scripts.

So, in short, I know it''s something we need to get better at. I
don''t
have any specific solutions right now, but I suspect this is the sort
of thing which will get addressed as the community evolves.

Cheers,
Andrew

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Andrew,

Thanks for the reply.  Yes, writing an extendSafely() extension sounds
like a good stop gap, and a marked improvement over the blatant
overwriting that often takes place.  It will certainly spare me a lot
of debugging headaches!

On Feb 18, 8:59 pm, Andrew Dupont
<goo...-TiabPMV39B5K4mp1Ns0Z8Q@public.gmane.org>
wrote:
> On Feb 18, 10:53 am, broberts
<brobert...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > I''ve found that one of the biggest arguments against
Prototype and
> > similar frameworks/libraries is the potential pitfalls of extending
> > core and client-side JavaScript.  One component of this argument is
> > the "risk" of name collisions or different programmers
overwriting
> > each other''s custom extensions.
>
> We acknowledge this risk; if it''s the sort of thing
you''re worried
> about, it''s a valid reason to choose another library.
>
> In Ruby, runtime augmentation of built-in classes is both permitted
> and encouraged. There are those who call Ruby developers rubes for
> working in an environment where this sort of "monkeypatching"
takes
> place, but somehow it all works out without the sky falling or the
> polar icecaps melting.
>
> In JavaScript, of course, it''s a bit different. The language
itself
> gives us fewer tools to manage the potential pitfalls of a
> heterogeneous scripting environment. We make the trade-off anyway,
> since we think the benefits outweigh the costs. But, yeah, the costs
> still piss me off.
>
> > SO...I was wondering if there are any plans to provide a mechanism in
> > Prototype to help detect or prevent accidental overwriting of DOM and
> > JavaScript object extensions.  It seems like it would save a great
> > deal of debugging time and frustration if Prototype''s
> > Element.addMethods() and Object.extend() both threw a JavaScript error
> > when trying to add an extension on a DOM or JavaScript object that
> > already exists.
>
> I can''t say we''ve got plans to do so, but it''d
be easy enough to write
> your own version of Object.extend that would ensure the properties
> you''re copying over don''t already exist:
>
> Object.extendSafely = function(destination, source) {
>   var keys = Object.keys(destination);
>   for (var i in source) {
>     if (keys.include(i))
>       throw "Collision: " + i + " already exists";
>   }
>   return Object.extend(destination, source);
>
> };
>
> This wouldn''t help if two third-party scripts are colliding with
each
> other, but it would help if a third-party script is colliding with
> code you wrote yourself.
>
> > I find, when I''m working with multiple third-party scripts, I
often
> > encounter accidental extension overwrites which are almost always
> > difficult to identify and debug.  In most cases, rather than throwing
> > a JavaScript error, the overwrites cause unexpected behavior.  So,
> > it''s often not clear if the script itself is the problem or
if some
> > type of accidental overwrite has occurred.
>
> > Can or will Prototype come to the rescue?
>
> I''m the first to admit we need to do better in cultivating a
third-
> party ecosystem for Prototype. Perhaps the first step is to assemble
> some ad-hoc best practices for Prototype add-on scripts.
>
> So, in short, I know it''s something we need to get better at. I
don''t
> have any specific solutions right now, but I suspect this is the sort
> of thing which will get addressed as the community evolves.
>
> Cheers,
> Andrew
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---

Andrew,

Thanks for the reply.  Yes, writing an extendSafely() extension sounds
like a good stop gap, and a marked improvement over the blatant
overwriting that often takes place.  It will certainly spare me a lot
of debugging headaches!

On Feb 18, 8:59 pm, Andrew Dupont
<goo...-TiabPMV39B5K4mp1Ns0Z8Q@public.gmane.org>
wrote:
> On Feb 18, 10:53 am, broberts
<brobert...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > I''ve found that one of the biggest arguments against
Prototype and
> > similar frameworks/libraries is the potential pitfalls of extending
> > core and client-side JavaScript.  One component of this argument is
> > the "risk" of name collisions or different programmers
overwriting
> > each other''s custom extensions.
>
> We acknowledge this risk; if it''s the sort of thing
you''re worried
> about, it''s a valid reason to choose another library.
>
> In Ruby, runtime augmentation of built-in classes is both permitted
> and encouraged. There are those who call Ruby developers rubes for
> working in an environment where this sort of "monkeypatching"
takes
> place, but somehow it all works out without the sky falling or the
> polar icecaps melting.
>
> In JavaScript, of course, it''s a bit different. The language
itself
> gives us fewer tools to manage the potential pitfalls of a
> heterogeneous scripting environment. We make the trade-off anyway,
> since we think the benefits outweigh the costs. But, yeah, the costs
> still piss me off.
>
> > SO...I was wondering if there are any plans to provide a mechanism in
> > Prototype to help detect or prevent accidental overwriting of DOM and
> > JavaScript object extensions.  It seems like it would save a great
> > deal of debugging time and frustration if Prototype''s
> > Element.addMethods() and Object.extend() both threw a JavaScript error
> > when trying to add an extension on a DOM or JavaScript object that
> > already exists.
>
> I can''t say we''ve got plans to do so, but it''d
be easy enough to write
> your own version of Object.extend that would ensure the properties
> you''re copying over don''t already exist:
>
> Object.extendSafely = function(destination, source) {
>   var keys = Object.keys(destination);
>   for (var i in source) {
>     if (keys.include(i))
>       throw "Collision: " + i + " already exists";
>   }
>   return Object.extend(destination, source);
>
> };
>
> This wouldn''t help if two third-party scripts are colliding with
each
> other, but it would help if a third-party script is colliding with
> code you wrote yourself.
>
> > I find, when I''m working with multiple third-party scripts, I
often
> > encounter accidental extension overwrites which are almost always
> > difficult to identify and debug.  In most cases, rather than throwing
> > a JavaScript error, the overwrites cause unexpected behavior.  So,
> > it''s often not clear if the script itself is the problem or
if some
> > type of accidental overwrite has occurred.
>
> > Can or will Prototype come to the rescue?
>
> I''m the first to admit we need to do better in cultivating a
third-
> party ecosystem for Prototype. Perhaps the first step is to assemble
> some ad-hoc best practices for Prototype add-on scripts.
>
> So, in short, I know it''s something we need to get better at. I
don''t
> have any specific solutions right now, but I suspect this is the sort
> of thing which will get addressed as the community evolves.
>
> Cheers,
> Andrew
--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---