On Wed, Jul 07, 2004 at 11:02:43PM +0900, James B Crigler wrote:
> I misstated the case here:  The status sets may have a few identical
> names, e.g., an Edibles could have a set of statuses like
> 	"CUT", "INSERT", "CHEW", "SWALLOW", "DIGEST"
> while a Readables class could have a set of statuses like
> 	"OPEN", "READ", "CONSIDER", "DIGEST", "MEDITATE"
> 
> Your Enum solution can't prevent me from comparing these two.

You may find enum.rb from rubycollections more to your liking, then:

  http://cvs.sourceforge.net/viewcvs.py/rubycollections/rubycollections/rbc/enum.rb

It has a very similar interface to the one on the addlib wiki (not
entirely an accident, since Tim's enum is based off my RCR and my RCR
was based off my implementation of enum :).

Differences between Tim's enum and the one in rubycollections:

  - Tim's enum doesn't work on 1.6.x; mine does (probably not an issue
    unless you work in a production environment where you are slow to
    upgrade, as we are where I work)
  - constants in Tim's enum are all the same class (Enum::Enumerator);
    rbc enum creates a new type whenever you call Enum.new.
  - Tim's enum has all the math operators that mine lacks (so you can
    easily replace code that uses the integer constants for doing bit
    operations with code that uses enums instead)
  - Tim's enum restricts you to using integers (not entirely a bad
    thing); mine allows the use of other types, such as strings (I've
    only rarely found a use for this; a hash would probably have done as
    well)
  - When inspected, Tim's enum prints both the name and the value of the
    enum, a very nice feature.

Also, something I didn't mention in the RCR but which would be nice is
the ability to create an enum from either a hash or an array, e.g.:

  Foo = Enum.new(:A, :B, :C)
  Bar = Enum.new(:A, 1, :B, 5, :C)
  Baz = Enum.new(:A => 1, :B => 5, :C => 6)

Paul