In article <m2ae3fuk7h.fsf / zip.local.thomases.com>,
Dave Thomas <Dave / PragmaticProgrammer.com> wrote:
>mirian / cosmic.com (Mirian Crzig Lennox) writes:
>
>> Anyway, I'm thinking that maybe it would be more intuitive to have ==
>> or === return true for two different Method objects if they both
>> reference the same underlying method.  What do you think?
>
>I'm not sure the semantics are that clear. For example, would this be
>the same method implementation, or the same method name? And is it the
>same method in the same object, the same method for any object of a
>particular class, of the same method globally?

Intuitively, I would expect it to be the implementation of the method.
If the two Method objects reference the same method implementation
(bytecode, or syntax tree, or however methods are stored internally)
then I would expect == to return true, and false otherwise.

I guess (without really having dug into the code) that I had just
assumed that that's what calling "method" would do: get you an object
which is "tied" in some manner to the low-level representation of a
particular method.  In Ruby, the only way to change a method at the
interpreter level is to define a new method, which would necessarily
be a different method (even if it contained identical code) and
therefore not be "equivalent" in the logical sense (unless of course,
Ruby is clever enough to detect when two different methods would have
the same internal representation, and avoid duplication).

On the other hand, this point of view is merely my own prejudice,
coming from the C/C++ world.  It may not be appropriate for the Ruby
way of doing things, and I'm not experienced enough to make that
assessment.

--Mirian