From: "David A. Black" <dblack@...>
Date: 2004-09-30T10:57:33+09:00
Subject: Re: AClass() vs. AClass[] constuctors (was Best name for "this method")

Hi --

On Thu, 30 Sep 2004, trans.  (T. Onoma) wrote:

> For reference:
> >
> >  class Object
> >    def const_get(c)
> >      self.class.const_get(c)
> >    end
> >    def const_set(c,v)
> >      self.class.const_set(c,v)
> >    end
> >  end
> >
> >  module Kernel
> >    alias method_missing_orig method_missing
> >    def method_missing(m,*a,&b)
> >      Class === (c = const_get(m)) ? c::new(*a,&b) :
> > method_missing_orig(m,*a,&b) 
> >    end
> >  end
> 
> David wrote:
> > I've lost track of where this is going a bit, but here you seem to be
> > making it look like non-module/class objects have constants:
> >
> >  a = ""
> >  a.const_set("X",1)
> >  p a.const_get("X")   # 1
> >
> > not to mention:
> >
> >  p String::X   # 1
> >
> >(i.e., indirect setting of a Class object's constant).  
> 
> Okay, perhaps they should be private. Beyond that, I'm not sure its really a 
> problem since one can just as easily do:
> 
>   self.class.const_set
> 
> Yes, this makes it clear that they are class level entities. But the former is 
> polymorphic. Perhaps you can show a good use case for why the former is not 
> good to have?

I'm not sure about a use case; it just doesn't fit the model.  Classes
and modules have constants; other objects, as far as I know, don't.
Having this kind of transparent delegation makes it seem like they do,
which is misleading.  

I also wouldn't want non-classes to start having superclasses, class
methods, etc., just because they have a class.  And if I were a Class,
I wouldn't want all my instances acting like me; I'm an object in my
own right :-)  


David

-- 
David A. Black
dblack@wobblini.net