From: dblack@...
Date: 2006-08-26T19:01:49+09:00
Subject: Re: Support for singleton_class() (was Re: Call functions of superclass)

Hi --

On Fri, 25 Aug 2006, ara.t.howard@noaa.gov wrote:

> On Fri, 25 Aug 2006 dblack@wobblini.net wrote:
>
>> I'd rather not see module_eval wrapped/hidden in singleton_class.  I
>> see singleton_class as a kind of twin method with class.  In part I'm
>> hoping for this because I think it will make it vastly easier for
>> people to understand the basic premise that an object has a [birth]
>> class and a singleton class, from both of which it draws its
>> behaviors.  I don't see an advantage to adding a special twist to
>> singleton_class.  If it gives you a class object, you can always call
>> module_eval on that, as with any class object.
>
> you could say exactly the same thing about Class.new, Module.new, etc.

Yes, but you *can't* say the same thing about #class, which is a more
level comparison with #singleton_class.

> i think the advatage is that
>
>  obj = Object.new
>
>  obj.singleton_class.module_eval{ def foo() 42 end }
>      ^^^^^^^^^^^^^^^ ^^^^^^^^^^^
>      ^^^^^^^^^^^^^^^ ^^^^^^^^^^^
>      hard to explain. harder.  where's the module?

Well, I was just using module_eval to match your usage; I would
normally use class_eval for a class :-)  I'm afraid I don't see what's
hard to explain or use about it.  You've got a method that returns a
Class object; you send a message to that Class object.  It seems like
the most natural possible kind of sequence.

> block methods in ruby save time and code scanning.

You're ascending to a kind of bird's-eye view, though.  When it comes
to any given specific method, I'd rather examine the suitability of a
block in close-up.  In this particular case, I dislike the prospect of
this equivalency:

   obj.class.class_eval { ... }  # class_eval one method away
   obj.singleton_class { ... }   # class_eval magically available


David

-- 
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
   ----> SEE SPECIAL DEAL FOR RUBY/RAILS USERS GROUPS! <-----
http://dablog.rubypal.com        => D[avid ]A[. ]B[lack's][ Web]log
http://www.manning.com/black     => book, Ruby for Rails
http://www.rubycentral.org       => Ruby Central, Inc.