Re: adding overload to ruby

On Fri, Sep 27, 2002 at 03:04:56PM +0900, Bulat Ziganshin wrote:
> bclrS20tse> - - It violates the spirit of Ruby. IMHO, anything that does
> 
> bclrS20tse>   raise ArgumentError unless ( foo.type? == String )
> 
> bclrS20tse>   does this as well. It short circuits much of the power of
> 
> well. say me exactly how many types you personally written which can
> be used instead on Integer or String? yaraa don't have even one

The average Ruby programmer arguably uses something more than Strings
and Integers.

I have a StringIO that responds to puts, read, write and a bunch of
other methods, which I happily pass in place of IO objects.

In writing code that handles node dependencies in a graph, I used
Hashes as nodes; then switched to a custom class nowhere near Hash in
the class hierarchy.  The custom class responds to [] and not a single
line in the code had to be changed.

The day a `feature' is added to Ruby that prevents things like these
is the day Ruby loses one developer (at the very least).

IMHO = true

(Which means: imagine a `I think that' before any sentence below.  I
don't write it just so that my writing keeps a hope of staying
readable.)

Typing is fine in procedural languages, where the thing being typed is
data, a passive and unsurprising entity.  But in OO, entities have
behaviours, too.

If you want to check whether someone should be allowed into
House#repair_pipes(plumber), you have some options.

1. You can check whether the plumber has a `Plumber' label printed on
   his forehead or whether his father was someone with a `Plumber'
   label.  That's what Java does.  But what if you want your cousin
   in, who happens to be good at repairing pipes?  Oh, yeah, you can
   always make both the plumber and your cousin take a certification
   in PlumbingPerson...  and of course, years later when a robot will
   come to repair those pipes, you'll dismantle the whole Plumbers'
   association to reassemble it with PlumbingBeing at the top, and, to
   their immense joy, robots will finally be able to get a `Plumber'
   (or equivalent) label on their metal forehead.

2. You can ask the plumber: ``Do you know anything about repairing
   pipes?''  That's what one does in Ruby when checking the result of
   plumber.respond_to?(:repair_pipes).  Nothing assures you that his
   pipes have to do with tubes and not with tobacco.  But nothing
   assures you that the `Plumber''s son hasn't become a vandal or the
   `Plumber' bot hasn't rebelled to humans, either.

3. You can just let everyone in and see if the house is still dry when
   they get out.  That's what many do in Ruby, since getting the house
   dry again is a matter of restarting the program.

4. You can just let everyone in and see if the house is still dry when
   they get out.  Then say out loud: ``Computer: holographic
   simulation over!''  That's what people do who do unit testing in
   Ruby.

I'm happy that Ruby doesn't restrict entrance based on labels printed
on foreheads.  I don't care if more widespread industry-standard
corporate-accepted buzzword-compliant languages do: they're wrong.
(Hey, remember that IMHO == true!)  It all boils down to the question:
do we already have optimal criteria of restricting objects?  (I say
no.)  If not and must be created from scratch, what would they be
like?

Before (and after) finding the answer, the way I'll go is unit
testing.  I'm sure sooo much feeling of uncertainty would go where it
belongs if only newcomers to Ruby got in touch with unit testing
early.

(Dave...  I know you're busy and that it's none of my business, but I
can't help fancying an appendix of the Pickaxe gently introducing the
Ruby-newbie to unit testing...)

Well, as far as quantity of objectionable content is concerned, I
guess I've just set a new record among my ruby-talk posts.  I hope
I'll survive the replies.


Massimiliano