From: Sean O'Halpin <sean.ohalpin@...>
Date: 2006-07-10T11:18:03+09:00
Subject: Re: Easy Pathname

On 7/9/06, Jeremy Henty <jeremy@chaos.org.uk> wrote:
> On 2006-07-08, transfire@gmail.com <transfire@gmail.com> wrote:
> >
> > Jeremy Henty wrote:
> >
> >> ... the convention already exists that Klass(x) means "coerce x to
> >> an instance of Klass", rather than "call Klass.new()".  As least it
> >> does for many values of Klass, so to make all instances of Klass()
> >> synonyms for Klass.new() would be seriously incompatible.
> >
> > Not so. Just becaue they would default to Klass.new does not mean
> > they could not be overriden with a variation of functionality -- as
> > is the case with some of those built in.
>
> Maybe, but how would it work?  On what criterion would you override?
> You'd want all calls to Klass() with a single argument to be
> interpreted as coercion, since one might in principle want to coerce
> any object to a <#Klass>.  So what do you do when it's natural to call
> Klass.new with one argument?  Maybe you could work around it, but I'd
> be worried you'd be making a messy situation even worse.
>
> I don't object to you doing this with your own classes, I just don't
> see a good way of extending this convention to *all* Ruby classes, at
> least not without breaking compatibility enough to rule it out for
> Ruby 1.x .
>
> Regards,
>
> Jeremy Henty
>
There's no need to introduce complicated rules for this. Just have
Klass() be a synonym for Klass.new() except for the built-in Kernel
methods. Even those could do with some rationalisation.

There are exactly four such methods in Kernel: String(), Integer(),
Float() and Array().

String(), Integer() and Float() coerce their arguments using to_s,
to_i and to_f respectively.

Array() is slightly more complicated trying to_ary, then to_a then
creating a single element array from the arg if the first two fail.

String.new accepts only strings. Integer and Float have no
corresponding new() method (as you yourself pointed out).

I see no reason why String.new couldn't use to_s on its args and why
there couldn't be Integer.new and Float.new with the same
functionality as Integer() and Float().

That only leaves Array.new, which to my mind is not the most intuitive
of methods anyway.
I would argue that it's a source of confusion that Array() and
Array.new behave so differently. However, changing this would break a
lot of code so it's probably best left alone.

I seriously doubt whether having Klass() = Klass.new() would break
much code. I think most people would be surprised to find out you can
even define a method with the same name as a class (I was).

With the scheme I've laid out, the only exception would be Array which
is already somewhat out on its own.

However, as you said, I can do this myself if I want to. I do and I
find it very convenient.

Regards,
Sean