From: Yehuda Katz Date: 2009-01-21T00:15:43+09:00 Subject: [ruby-core:21462] Re: Proposal: Module#copy_method --000e0cd29618bcd9b90460eb88bc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 On Tue, Jan 20, 2009 at 12:09 AM, Yukihiro Matsumoto wrote: > Hi, > > In message "Re: [ruby-core:21439] Re: Proposal: Module#copy_method" > on Tue, 20 Jan 2009 05:14:49 +0900, Charles Oliver Nutter < > charles.nutter@sun.com> writes: > > |> I am afraid it's too much restriction for OP's use-case, since so many > |> methods are implemented in C. > | > |The JRuby example I posted does filter out native methods. I agree > |that's a necessary minimum restriction in order to support this. I do > |not think it's too limiting a restriction for copy_method to be useful > |though. > > Although Yehuda (OP) also suggested the same limitation, I am strongly > against. Ruby does provide little or no distinction between C > implemented methods and Ruby implemented ones. I would not feel > reasonable when I see unexpected error to copy some methods, where > other methods can be copied. This enhancement cannot have a place in > the built-in methods. It should be separated library at most. > > matz. > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --000e0cd29618bcd9b90460eb88bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For my use-case, it would be ok to support copying methods to ANY module, a= nd then raise an exception at runtime if the module was included into an in= compatible class. This is *kind* of possible in 1.8 (with problems with sup= er) and not really possible in 1.9.

I would also be willing to write something along the lines o= f the use case in the OP as a patch (which would work with all methods).

-- Yehuda

On Tue, = Jan 20, 2009 at 12:09 AM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Hi,

In message "Re: [ruby-core:21439] Re: Proposal: Module#copy_method&quo= t;

on Tue, 20 Jan 2009 05:14:49 +0900, Cha= rles Oliver Nutter <charles.nu= tter@sun.com> writes:

|> I am afraid it's too much restriction for OP's use-case, sinc= e so many
|> methods are implemented in C.
|
|The JRuby example I posted does filter out native methods. I agree
|that's a necessary minimum restriction in order to support this. I do<= br> |not think it's too limiting a restriction for copy_method to be useful=
|though.

Although Yehuda (OP) also suggested the same limitation, I am strongl= y
against. Ruby does provide little or no distinction between C
implemented methods and Ruby implemented ones. I would not feel
reasonable when I see unexpected error to copy some methods, where
other methods can be copied. This enhancement cannot have a place in<= br> the built-in methods. It should be separated library at most.

&nbs= p; &n= bsp; matz.

--
Yehuda Katz
Develope= r | Engine Yard
(ph) 718.877.1325

--000e0cd29618bcd9b90460eb88bc--