[ruby-core:21481] Re: Proposal: Module#copy_method

What you're suggesting could certainly work; I was looking for the least
invasive possible change to Ruby's core that would still support an AOP DSL.
Your suggestion is likely invasive enough to end up being a long-standing
attempted project (it has been "in progress" at least since 2005), since it
would mean that the AOP specifics would need to be implemented in core, as
opposed to providing facilities for implementing it in pure Ruby which could
then be rolled back in once the implementation is worked out.
-- Yehuda

On Tue, Jan 20, 2009 at 9:13 AM, Brian Mitchell <[e-mail]> wrote:

> On Tue, Jan 20, 2009 at 10:15, Yehuda Katz <[e-mail]> wrote:
> > For my use-case, it would be ok to support copying methods to ANY module,
> > and then raise an exception at runtime if the module was included into an
> > incompatible class. This is *kind* of possible in 1.8 (with problems with
> > super) and not really possible in 1.9.
> > I would also be willing to write something along the lines of the use
> case
> > in the OP as a patch (which would work with all methods).
> > -- Yehuda
>
> I wonder if your specific use case might have other solutions that
> involve changes to Ruby which do not have such specific drawbacks?
>
> Bringing back Matz's slides from 2005 [0] we can see some concepts of
> what some extensions might look like. Right now those seem to use
> implicit calls to the original method. Might there be a way to set a
> reference to the intended super method to override basic dispatch in a
> method context? Specifically, a method could compile to a node which
> sets up some special info inside the call context which is checked
> which is checked for when super is looked up. This could also possibly
> be shared with method lookup caches.
>
> I'm not an implementation expert but this seems much more likely to
> work well with C methods and avoids the whole copy method problem. If
> a method needs moving, delegation is likely to be the best pattern.
> Unless someone can come up with a different use of method copying [1]
> I would oppose such a change.
>
> Brian.
>
> [0]: http://www.rubyist.net/~matz/slides/rc2005/mgp00034.html
> [1]: I assume that experiments with self-style activated slots would
> count as mostly experimental and can usually be best done with vclass
> semantics already. Also, this is the sort of case where being able to
> uninclude a module might be interesting.
>
>


-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325