From: dblack@...
Date: 2006-10-12T09:08:15+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:
>
>>> On Oct 11, 2006, at 3:13 PM, 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 agree with David's point about the discrepancy but couldn't that
>>> be also resolved by changing the standard #class method to behave like
>>> Ara's proposed #singleton_class ?
>> 
>> Yes, but that seems awfully magic and hidden.  I don't see what there
>> is about querying an object for its class that suggests a context for
>> an implied class_eval.
>
> the same thing that implies one for class creation
>
>  Class.new{
>
>  }
>
> we could easily just do
>
>  Class.new.class_eval{
>
>  }

I've actually always thought that new-with-block was a bit of a
stretch :-)

> i might add that any of them is less esoteric than
>
>  class << self
>
>    :wtf
>
>  end
>
> implying ducking into an object's singleton class

I don't think that's esoteric; it's just the way the class keyword
works: it takes either a constant, or a "<< object" expression (which
might be verbalized as "from this object" or something like that).

> for that matter, why should
>
>  class PreExistingClass
>
>    :at_least_this_makes_sense
>
>  end
>
> do a class_eval, rather than clobber a class?

It doesn't exactly do a class_eval, from the scoping perspective.  But
in any case it's a bit far afield.  Let's say (argumentum ex concessis
:-) that class PreExistingClass not clobbering a class made *no*
sense.  How would it follow that it's a good idea for #class to take a
block?

> it also seems POLS - when has anyone every wanted a singleton_class
> __except__ to evaluated code it in.  plus, what other meaningful
> semantic would passing a block to a class do?

POLS is *so* 2002 :-)  But anyway -- you're not passing the block to a
class, exactly; you're supplying the block to a method that returns a
class.  The question is how the block pertains to the work of the
method.  That's where I don't see the relevance.

> i love being devil's advocate ;-)

NOW you tell me?! :-)  I have to say, as much as I don't see the logic
of obj.class taking a block, I'd certainly rather have #class and [the
hopefully future] #singleton_class behave the same as each other in
that respect, whatever the behavior is.


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