Hi Robert,
That's a very interesting use case, thanks for that. I can certainly
see the utility of that, and in fact as I was writing all of this up
for my (pathetic little) blog I was getting increasingly uncomfortable
with the mixin issue.
If it's important for mixins to participate in hierarchy, it occurs to
me that my second point (saying they can't) is unduly pessimistic. Of
course they can. Unlike subclass methods, it's important that we
don't modify them directly, but that doesn't mean they can't play. In
this one special case where we basically have no choice, we can allow
ourselves the indirection and wrap them, modifying the wrapper rather
than the original. That costs a closure per mixin method (not on
every call, just at mixin-time), and then an extra #apply on each
mixin call. Still much more efficient than what we currently have,
and it keeps mixins fully able to participate in the hierarchy.
That's much more satisfying that shutting them out (and potentially
breaking the chain).
Thanks again,
-- T.J.
On Sep 9, 4:00 pm, Robert Kieffer <bro...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
