From: "trans.  (T. Onoma)" <transami@...>
Date: 2004-09-29T08:57:27+09:00
Subject: Re: Best name for "this method" ?

On Tuesday 28 September 2004 06:31 pm, David A. Black wrote:
> > Right. Well then, I must propose that all such class names be constructor
> > methods too. No sense in confusing things otherwise. By default:
> >
> >   def AClass(*args, &blk)
> >     AClass.new(*args, &blk)
> >   end
>
> I'm not getting the point of that.  Why do you need a wrapper like
> that around new?  Also, the one somewhat common case of this --
> Integer -- isn't a wrapper for new, since there is no Integer.new.  So
> you'd be introducing a constraint that currently doesn't exist.

Sorry, I should explain better. Let me put it this way: Why would I want to 
write a constructor like Hash[], when it could just as well be written 
Hash()? And in fact I don't --I cannot think of a single time that I have 
used the later notation. Why? *Not* because it isn't useful, but rather b/c 
it obfuscates my code b/c is looks like an Array or Hash lookup, and not like 
calling a constructor method.

> > But for something like Hash, it would be defined like Hash[].
>
> What is "something like Hash" in this context?  I'm not following
> here.

In other words, I am not saying it has to be X() == X.new(). Rather Hash() can 
do what Hash[] does. And likewise for Integer(). They are specialized 
constructor methods.

So my point, really, is simply, why not have this be default behavior for all 
classes? Specialized forms can be specially defined, the others can be 
equivalent to #new. Personally I like the look of it too.

T.