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

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

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

if i have a lib that does this

   exit if bug

then i can use it like this

   require 'lib'

or like this

   successfully_loaded = Thread::new {
     begin
       require 'lib'
       true
     rescue SystemExit
       nil
     end
   }.value

   puts "Thread#exit called in lieu of Kernel#exit - whew" unless successfully_loaded


the interface polymorism gained by synonyms is often handy.

if i design a table class an initially design it around a hash and use

   table.store key, value

in my code, but later decide i need to store multiple values under one key and
switch to a database backend i can simply have a store method that looks like

   def store key, *values
     ...
   end

and then start using

   table.store key, v0, v1, v2

without changing the other code.  if i'd used

   table[key] = value

all over the plase initially i'd have a strange mixture of methods and would
require a special [] method for storing one value, which would quickly become
code smell.  in this case the abstract idea of 'storing' something under a key
was more appropriate to my design in the first place so using this interface
saved me grief later.

synonyms exist elsewhere for clarity in ruby too

   unless == if not

thankfully.

regards.

-a
-- 
strong and healthy, who thinks of sickness until it strikes like lightning?
preoccupied with the world, who thinks of death, until it arrives like
thunder?  -- milarepa