Does Ruby not support multiple "initialize" methods for a class?

ruby-talk
21

Trust me -- I have no interest in shoehorning anything into a Java or
C++ mold. That wasn't my point.

···

On Wed, Mar 21, 2007 at 10:30:56AM +0900, Nando Sanchez wrote:

Hi Chad! I don't think Ruby "lacks" anything, it's just that it has a
different way of doing things. It's a trade-off between the flexibility
of a dynamic language and some other things like methods with same name
and different parameters (how are you going to distinguish between one
method that uses a string and an integer and another one that uses an
integer and a hash, if you don't have types defined at the parameter
level?). If you want to do things "like Java" or "like C++", then I
think you should open your mind and try to do things in a different way,
in a rubbish way.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"The first rule of magic is simple. Don't waste your time waving your
hands and hopping when a rock or a club will do." - McCloctnick the Lucid

22

and this doesn't even take into account the confusion that can be heaped upon
the programmer when default parameters are thrown into the mix. if parameter
overloading were allowed in ruby we could have this:

   def m int
     p int
     p 42.0
   end

   def m int, float = 42.0
     p int
     p float
   end

   m 42

now, which one is called? in order to understand this kind of stuff in c++
you have to become the compiler.

it's even worse when you can do

   m *args # yikes, which one is called?

no thanks!

cheers.

-a

···

On Thu, 22 Mar 2007, Florian Frank wrote:

I don't consider this to be a pattern, I consider overloading constructors
an anti-pattern.

One of the few good Java books (among all the mediocre or even worse ones)
is "Effective Java" by Joshua Bloch:

Oracle Java Technologies | Oracle

In the first chapter (actually chapter 2) in the first item Bloch advises
Java programmers to consider using static factory methods instead of public
and/or overloaded constructors. He lists the following advantages:

: One advantage of static factory methods is that, unlike constructors, they have names.
: If the parameters to a constructor do not, in and of themselves, describe the object being
: returned, a static factory with a well-chosen name can make a class easier to use and the
: resulting client code easier to read.
: [...]

The same is true in Ruby, if you use class methods (methods of a class's
eigenclass). The workarounds in the initialize method even *look* code
smelly. In Java overloading a constructor once or twice doesn't seem to be
such a bad idea. But other programmers tend to just copy and paste another
constructor below the others. Once you have a class that comes into the two
digit range of constructors, it gets quite difficult to remember all the
different possible permutations of types. (Yes, I had to maintain code like
that.)

And I think, overloading in general isn't such a good idea either. It can
lead to really funny semantic errors, if it teams up with Java's numeric
type promotion for example. (Yeah, this happened to me, too.)

--
be kind whenever possible... it is always possible.
- the dalai lama

23

<snip>

In the interest of ridiculousness, how about using the multi gem for
this? :slight_smile:

require 'rubygems'
require 'multi'

class Foo
  def initialize(*args)
    multi(:init, Integer) { |i|
      puts 'integer used'
      # do integer stuff...
    }

    multi(:init, Float) { |f|
      puts 'float used'
      # do float stuff...
    }

    init(*args)
  end
end

Heh, that interface is very similar to Nobu's overload package. [1]
There's also Ryan's strongtyping package for simulating overloaded
methods. [2]

Regards,

Dan

[1] http://www.rubyist.net/~nobu/ruby/overload-0.6.tar.bz2
[2] http://raa.ruby-lang.org/project/strongtyping/

PS - Nobu, you need to update your RAA link for the overload
package. :slight_smile:

···

On Mar 20, 10:15 am, "Mat Schaffer" <scha...@gmail.com> wrote:

24

I'm a fan of Ruby's dynamic typing. When I want type inference, I use
OCaml instead. My thought is not that I should have one language that
does everything, but that each language I have available is optimally
useful for the tasks in which I choose to employ it.

That being said . . . I'm not saying we should necessarily have
overloading in Ruby. I just wonder if there might be another way to
solve the same problem without having to resort to development patterns
to "work around" a lack of easy functionality. I'm not entirely sold on
the idea that there's enough "working around" to bother in this case,
but there might be.

Thus, my question.

···

On Wed, Mar 21, 2007 at 10:36:05AM +0900, Daniel Berger wrote:

Not true. Perl 6 will have optional static typing [1]. Sydney faked it
with a Behavior you could import (that used the parser to handle it, not
a compile time step, IIRC).

It's possible. The question is whether or not it's desirable. I vote
yes, others say no, and still others are in favor of some sort of type
inferencing. It's been brought up before - you can search the archives. :slight_smile:

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.

25

Why do people want to do this? Other than just to do it. What was it about C letting you shoot yourself in the foot, and C++ letting you blow your whole leg off...

···

On Mar 22, 2007, at 6:28 AM, ara.t.howard@noaa.gov wrote:

On Thu, 22 Mar 2007, Florian Frank wrote:

I don't consider this to be a pattern, I consider overloading constructors
an anti-pattern.

One of the few good Java books (among all the mediocre or even worse ones)
is "Effective Java" by Joshua Bloch:

Oracle Java Technologies | Oracle

In the first chapter (actually chapter 2) in the first item Bloch advises
Java programmers to consider using static factory methods instead of public
and/or overloaded constructors. He lists the following advantages:

: One advantage of static factory methods is that, unlike constructors, they have names.
: If the parameters to a constructor do not, in and of themselves, describe the object being
: returned, a static factory with a well-chosen name can make a class easier to use and the
: resulting client code easier to read.
: [...]

The same is true in Ruby, if you use class methods (methods of a class's
eigenclass). The workarounds in the initialize method even *look* code
smelly. In Java overloading a constructor once or twice doesn't seem to be
such a bad idea. But other programmers tend to just copy and paste another
constructor below the others. Once you have a class that comes into the two
digit range of constructors, it gets quite difficult to remember all the
different possible permutations of types. (Yes, I had to maintain code like
that.)

And I think, overloading in general isn't such a good idea either. It can
lead to really funny semantic errors, if it teams up with Java's numeric
type promotion for example. (Yeah, this happened to me, too.)

and this doesn't even take into account the confusion that can be heaped upon
the programmer when default parameters are thrown into the mix. if parameter
overloading were allowed in ruby we could have this:

  def m int
    p int
    p 42.0
  end

  def m int, float = 42.0
    p int
    p float
  end

  m 42

now, which one is called? in order to understand this kind of stuff in c++
you have to become the compiler.

it's even worse when you can do

  m *args # yikes, which one is called?

no thanks!

cheers.

-a
--
be kind whenever possible... it is always possible.
- the dalai lama

26

Speaking with my C++ compiler hat on, I believe the answer is "Ambiguous
function call; please be more specific" (your compiler error may vary).

But your point is well-taken.

···

On 3/21/07, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:

   def m int
     p int
     p 42.0
   end

   def m int, float = 42.0
     p int
     p float
   end

   m 42

now, which one is called? in order to understand this kind of stuff in
c++
you have to become the compiler.

--
Avdi

27

Hi --

>
> Not true. Perl 6 will have optional static typing [1]. Sydney faked it
> with a Behavior you could import (that used the parser to handle it, not
> a compile time step, IIRC).
>
> It's possible. The question is whether or not it's desirable. I vote
> yes, others say no, and still others are in favor of some sort of type
> inferencing. It's been brought up before - you can search the archives. :slight_smile:

I'm a fan of Ruby's dynamic typing. When I want type inference, I use
OCaml instead. My thought is not that I should have one language that
does everything, but that each language I have available is optimally
useful for the tasks in which I choose to employ it.

That being said . . . I'm not saying we should necessarily have
overloading in Ruby. I just wonder if there might be another way to
solve the same problem without having to resort to development patterns
to "work around" a lack of easy functionality. I'm not entirely sold on
the idea that there's enough "working around" to bother in this case,
but there might bere

Thus, my question.

I think the availability of the allocate method is very characteristic
of Ruby, and not a workaround. It's just Ruby being Ruby. One thing
I've always loved about Ruby is that it lets you do things through
composition of simple techniques that are virtually equivalent to
language-level constructs and facilities in other languages. The
classic examples are "attributes" and "class methods." All you need
to create attributes in Ruby is:

  1. instance variables
  2. methods

and (almost) all you need for class methods (except a bit of
inheritance special-casing) is:

  1. objects can have singleton methods
  2. classes are objects.

It's like Ruby is saying, "You want 'attributes'? OK. Here. Now
you've got 'attributes'." :slight_smile: It's all built on the simplest possible
things in Ruby, and on not very many of them.

Multiple constructors seem to fall into that category. All you have
to do is use allocate, and you can have as many constructors as you
need.

I wonder what lies ahead. I mean, look how easy it is to conjure up
things like attributes and class methods from the building blocks that
Ruby offers. The things that get conjured up tend to resemble things
from other languages -- but maybe there are entirely new constructs
waiting to arise out of Ruby's components.

David

···

On 3/20/07, Chad Perrin <perrin@apotheon.com> wrote:

On Wed, Mar 21, 2007 at 10:36:05AM +0900, Daniel Berger wrote:

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black\)
   (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf\)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

28

Hmm. I like that explanation. It'll bear some thought.

Thanks.

···

On Wed, Mar 21, 2007 at 12:27:04PM +0900, David A. Black wrote:

It's like Ruby is saying, "You want 'attributes'? OK. Here. Now
you've got 'attributes'." :slight_smile: It's all built on the simplest possible
things in Ruby, and on not very many of them.

Multiple constructors seem to fall into that category. All you have
to do is use allocate, and you can have as many constructors as you
need.

I wonder what lies ahead. I mean, look how easy it is to conjure up
things like attributes and class methods from the building blocks that
Ruby offers. The things that get conjured up tend to resemble things
from other languages -- but maybe there are entirely new constructs
waiting to arise out of Ruby's components.

--
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"A script is what you give the actors. A program
is what you give the audience." - Larry Wall

29

This statement reminds me of something Alan Kay said to me after he
had given a talk on Smalltalk at IBM. He said that one of his
disappointments was that no one ever seemed to make new subclasses of
Behavior (which in Smalltalk is the abstract class which both Class
and Metaclass subclass).

···

On 3/20/07, David A. Black <dblack@wobblini.net> wrote:

I wonder what lies ahead. I mean, look how easy it is to conjure up
things like attributes and class methods from the building blocks that
Ruby offers. The things that get conjured up tend to resemble things
from other languages -- but maybe there are entirely new constructs
waiting to arise out of Ruby's components.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/