Hi --

On 3/20/07, Chad Perrin <perrin / apotheon.com> wrote:
> 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. :)
>
> 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'." :-)  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

-- 
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)