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

On Wed, Sep 9, 2009 at 7:29 AM, T.J. Crowder<> wrote:
> Hi all,
> I thought of a wrinkle today:  Mixins.  This new mechanism modifies
> function instances if they override base class functions (it leaves
> them alone if they don't).  So if you mix in something that has a
> function with the same name as a parent class's function, we will set
> a $super property on the mixin function's instance.  That seems wrong
> to me, mixins should be read-only as far as the mechanism is
> concerned, IMHO.
> Now, in _practical_ terms, unless the mixin function calls $super
> (which seems an odd thing for a mixin to do, but I can come up with an
> edge case use case for it), it doesn't matter much.  But if A) the
> mixin function does (presumably optionally) call $super, and B) more
> than one class mixes the mixin in, AND C) the mixin overrides one of
> the functions in at least one of those classes, you get class
> crosstalk -- a very bad thing.
> My first thought for how to deal with this was stupid and I'll spare
> you.
> My *second* (hopefully not stupid) thought was to mark mixin functions
> with a property telling us to leave them alone.  I see two
> ramifications to doing that:
> 1. An API change:  To define a mixin, you'd ideally want to run it
> through something (something we'd presumably provide) that spins
> through and marks the functions so we leave them alone.
>    var MyMixIn = Class.createMixin(...);
> 2. Mixins can't even optionally participate in supercalls, which they
> can with the current mechanism.
> Now, for me, #2 is not a problem.  I'm not thrilled about introducing
> #1, although really you only have to do that to protect against an
> edge case you're probably not going to run into.  It's someting a
> library of mixins would want to be sure to do, but within a non-
> library project, not sure it really matters.
> -- T.J.
> On Sep 9, 9:28 am, Jim Higson <> wrote:
>> On Wednesday 09 September 2009 09:02:28 Jim Higson wrote:
>> > > I see where you're coming from, but FWIW I'm with Allen on this one.
>> > > Also, there's no standard way to get the name of a function until
>> > > ECMAScript5 (which standardizes the truly outrageous idea that
>> > > function instances should have -- gasp! -- a "name" property), and at
>> > > the moment although Firefox 3.5, Chrome 2, and Safari 4 all already
>> > > have that property, IE7 (at least, haven't tested IE8) and Opera10 do
>> > > not.
>> > I have a hunch we could get function names in the same way that we
>> > implement Function#argumentNames. A regex on the toString.
>> I should have looked first - this is function decompilation and considered a
>> bad thing.
>> --
>> Jim
>> my wiki ajaxification thing:
>> my blog:
> >

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

Reply via email to