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){...},
deselectItem:function(item){...},
getSelectedItems: function() {...},
// Make sure we deselect items before they're removed
remove: function($super, item) {
this.deselectItem(item);
$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
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---
