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

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.