I'm with Allen on this.  I don't think it's uncommon for mixins to want to
hook into existing functionality.  This is trivial if they can invoke $super
(the original object's method), and problematic otherwise.

To give a concrete example, a while ago I implemented a "Selectable" mixin
for some collection classes.  Because this mixin maintained the selection
state in a private cache, it needed to hook into the remove() method to
allow it to properly update the cache.  Thus, I could easily see doing
something like this:

var Selectable = Class.createMixin({
  // Various methods we add to the collection class...
  selectItem: function(item){...},
  getSelectedItems: function() {...},

  // Make sure we deselect items before they're removed
  remove: function($super, item) {

On Wed, Sep 9, 2009 at 7:31 AM, Allen Madsen <bla...@gmail.com> wrote:

> TJ,
> I don't particularly think this is a problem or even a new problem
> (wouldn't the current let you do this as well?). This sounds like
> protecting the developer from themselves. I think as long as you
> sufficiently state what will happen in a particular instance then it
> is perfectly reasonable to allow each individual developer to handle
> it as they see fit.
> Allen Madsen
> http://www.allenmadsen.com

You received this message because you are subscribed to the Google Groups 
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to