Mark Volkmann
1/19/2006 6:41:00 PM
On 1/19/06, James Britt <james_b@neurogami.com> wrote:
> Mark Volkmann wrote:
> > On 1/19/06, Kenneth Collins <pine29@myfastmail.com> wrote:
> >
> >>John, pick out the way to do something that seems most natural to you
> >>and get familiar with that. Then ignore the rest. I think Ruby's "more
> >>than one way to do it" was intended as a blessing, not a burden.
> >
> >
> > That's not really good enough though. I you ever have a need to read
> > Ruby code that someone else wrote, you'll have to understand every way
> > to do something. I love Ruby, but I'm not yet a fan of having many
> > ways to do something unless there are cases where each possible
> > approach is better than the others.
>
> How many different ways are there for doing various tasks? 2? 3?
>
> For how many fundamental operations?
>
> Do the variations follow some general pattern or principle?
>
> Can anyone offer examples of multiple ways of doing something
> fundamental, and point out where it may be confusing?
I guess I'm more annoyed by synonyms than multiple syntax approaches
because there don't seem to be too many of those.
> I've read complaints about Ruby allowing both if/then and unless/then,
> as well as the option to put the test either at the start or end of the
> expression. I don't find this a remarkably complex idea, but perhaps if
> it is poorly introduced then the options may seem arbitrary.
>
> > A particular thing I dislike is synonyms for methods in the built-in
> > classes. Sure I can choose to use the method name that makes the most
> > sense to me, but I still have to be aware of all the synonyms so I can
> > read code that others wrote.
>
> In the long run I'd rather have to periodically go to ri or ruby-doc to
> learn something if it means I can choose message names that better
> express my intentions.
I guess that's the part I don't get. In the majority the cases, I
don't see how choosing a particular synonym better expresses the
intention.
For example, in the Hash class, has_key? = include? = key? = member?
When I see include? and member? it's not immediately obvious to me
whether they test whether a given object is present as a key or a
value. has_key? and key? are more clear and I don't see a benefit to
having both of them.
That may be the best example. Here are some others.
Enumerable:
collect = map
entries = to_a
detect = find
member? = include?
find_all = select
Hash:
store = []=
merge! = update
has_value? = value?
Integer:
next = succ
IO:
pos = tell
Kernel:
fail = raise
format = sprintf
String
next = succ
next! = succ!
Thread
fork = start
exit = kill = terminate
In most of these cases you could argue that one would guess that they
are synonyms. Still I think many will have nagging doubts about
whether there are subtle differences and decide to take the time to
look up their definitions. For example, is Thread.kill really the same
as Thread.exit? kill sounds so ominous. Maybe there is a small
difference, you'll think to yourself. Verifying these things makes it
take longer to read code, which is really the main point of my rant.
--
R. Mark Volkmann
Partner, Object Computing, Inc.