On Mar 2, 2007, at 7:54 AM, Leslie Viljoen wrote:
> Is it *really* a problem that strings and integers produce values that
> your method would make use of? Say someone wants to encode those input
> parameters into a string - as long as [] works, they can. Why is this
> a problem?

As a general response, I'd say that there is a strong semantic
difference between objects that store key/value pairs (Hash,  
OrderedHash,
RBTree, etc.) and objects that aren't general collections but do
have some sort of indexing features (Integers, Strings).  Arrays are
sort of in the middle.

You certainly can consider integers as ordered collections of bits  
and strings
as collections of bytes (and sometimes that would be just great) but at
other times I think it is reasonable to consider integers
and strings as distinctly different than a hash or a tree.

I suppose this is a general problem of agreeing on some sort of  
taxonomy for
data structures and being able to dynamically query for various  
features.
Smalltalk pushes this a lot farther than Ruby: Dictionary,  
IdentityDictionary,
Bag, Set, SortedCollection, ArrayedCollection, ByteArray, String,  
Text, Array,
RunArray, LinkedList, OrderedCollection.

Usually I would avoid introspection on an object but it seems like  
when you
are designing DSLs and/or dealing with object construction it is  
sometimes
necessary to be a little more nosey.

I'm going to stick with testing for #fetch when I want to know if an  
object
is a collection with keys.  I think this is marginally better than using
(Hash === obj).  I can always test for #at if I want to pick out Arrays.

Gary Wright