From: Mark Volkmann <r.mark.volkmann@...>
Date: 2006-01-20T04:49:38+09:00
Subject: Re: My Thought on the "Pickaxe book" (from a Ruby novice)

On 1/19/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> On Fri, 20 Jan 2006, Mark Volkmann wrote:
>
> > 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.
>
> i couldn't disagree more.  names, for variables or methods, are of utmost
> importance to better expresses intention:
>
>    puts 'this makes sense even without knowing what set is!' if set.member? 42
>
>    puts 'this is requires a comment' if s.has_key? 42

Good example. I guess what I'm looking for is an example of when
set.has_key? expresses intent better than set.member?. If there is no
such case then it seems to me the Set class shouldn't support
has_key?. Maybe this is related to what James said about being able to
use a different class without changing the code .. switching from a
Set to a Hash.

> > That may be the best example. Here are some others.
> >
> > Enumerable:
> >  collect = map
> >  entries = to_a
> >  detect = find
> >  member? = include?
> >  find_all = select
>
>    p signals.detect{|sig| sig.freq > 42}
>
>    p list.find{|x| x.freq > 42}

That seems like a domain-specific example. I guess you're saying that
you detect signals, you don't find them. I feel like Ruby would really
be a mess if we added lots of domain-specific method names to the
built-in classes.

> > 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
>
> for many synonyms consider duck typing usage as well - it's not only about
> making sense when reading:

Yes, that makes sense. I guess you could say that having synonyms
allows you to decide on a case-by-case basis whether you care more
about readability or the ability to change classes later without
changing code (for example, the case James pointed out where he could
switch between an Array and a Hash).

--
R. Mark Volkmann
Partner, Object Computing, Inc.