From: dblack@...
Date: 2006-10-12T05:41:05+09:00
Subject: Re: Singleton Class Constants

Hi --

On Thu, 12 Oct 2006, ara.t.howard@noaa.gov wrote:

> On Thu, 12 Oct 2006 dblack@wobblini.net wrote:
>
>> I prefer it without that, since that makes it deviate from the #class
>> method, which it's otherwise precisely parallel to.  I'd rather that
>> singleton_class work like class than that it work like class_eval.
>> Otherwise you've got a situation where all classes except singleton
>> classes have to call class_eval, and I don't see any grounds for
>> granting that privilege.
>> 
>> (I know we've hashed through this before, and don't agree; I just
>> wanted to summarize the dissident position :-)
>
> hmm.  i don't disagree completely - i would just say that those other 
> methods,
> 'class' for example, should take blocks.  blocks are 25% of the reason ruby 
> is
> so beautiful and clean looking.  compare
>
>  def foobar
>    class{ attr 'added_a_class_attr' }
>  end
>
> with
>
>  def foobar
>    class.class_eval{ attr 'added_a_class_attr' }
>  end
>
> one word, i realize, but open{} only saves a close too - they add up!

Well... it has to be self.class :-)  But in any case, though I'm a big
fan of Ruby's expressive power, I don't think it's rooted in pruning
away method calls as an end in itself.  open is an operation with
extent in time, and a block is good at meshing with that.  class_eval
is also such an operation -- but just retrieving the name of a class
isn't.

(I'm not saying that "extent in time" is the only block-worthy thing,
but I just can't see how obj.class suggests any kind of segue to a
blockwise operation.)


David

-- 
                   David A. Black | dblack@wobblini.net
Author of "Ruby for Rails"   [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB's Weblog)        [2] | Co-director, Ruby Central, Inc.   [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com    | [4] http://www.rubycentral.org