On 7/9/06, Jeremy H. [email protected] wrote:
they could not be overriden with a variation of functionality – as
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 .
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.