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.
-
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.
-
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.
-
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.
-
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
···
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
