From: "trans.  (T. Onoma)" <transami@...>
Date: 2004-09-30T09:04:49+09:00
Subject: AClass() vs. AClass[] constuctors (was Best name for "this method")

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?

But the above issue aside, this was just the solution I next derived. I'm sure 
there is a more appropriate way to code this method_missing handler --namely 
keeping it in-line with the proper module namespace rules. Perhaps this is 
better:

  class Module
    def method_missing(m,*a,&b)
      Class === (c = const_get(m)) ? c::new(*a,&b) : super
    end
  end

  class Object
    def method_missing(m,*a,&b)
      Class === (c = self.class.const_get(m)) ? c::new(*a,&b) : super
    end
  end

Better suggestions?

T.