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 <j...@wikizzle.org> 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:http://wikizzle.org
> my blog:http://jimhigson.blogspot.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
-~----------~----~----~----~------~----~------~--~---

Reply via email to