From: ara.t.howard@...
Date: 2006-10-12T05:41:13+09:00
Subject: Re: Singleton Class Constants

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 might add that any of them is less esoteric than

   class << self

     :wtf

   end

implying ducking into an object's singleton class


for that matter, why should

   class PreExistingClass

     :at_least_this_makes_sense

   end

do a class_eval, rather than clobber a class?


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?

i love being devil's advocate ;-)

-a
-- 
my religion is very simple.  my religion is kindness. -- the dalai lama