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

On Wednesday 29 September 2004 09:57 pm, David A. Black wrote:
> 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 :-)

Oh, dear. I fear that's taking it quite too far --and very far from the topic, 
which I prefer to focus. As to the avantages and disadvantages of 
class/object polymorphic behavior vs. proper jurisdictions, let us leave for 
another thread. I was never trying to push for those cont_get/set methods 
anyway, they were just an exampled means to an end.

So back to point. To me the Class[] constructor notation is poor, and Class() 
is much preferable. Note, I am not advocating a replacement for .new(), as I 
think some have taken it. Nor am I suggesting filling-up Kernel space. Nor 
that my example method_missing means is the proper approach. Rather, it would 
simply be a special class constructor that one could define in the classes, 
and would default to Class.new.

T.