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 On Wed, Sep 9, 2009 at 7:29 AM, T.J. Crowder<t...@crowdersoftware.com> 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 <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 -~----------~----~----~----~------~----~------~--~---
