Hi --

On Fri, 2 Mar 2007, James Edward Gray II wrote:

> Yeah, you're right.  I was feeling that this is just an attempt to 
> sidestep type checking by inventing a clever new type checking system.

Or an attempt to sidestep class-checking by inventing a type-checking
system :-)  A few years ago there were some interesting attempts to
come up with a systematic way to determine an object's type, in the
sense of its full profile and interface, at any given point in its
life.  The idea was to be able to get some kind of rich response from
the object, well beyond what respond_to? and is_a? provide, in order
to determine whether you'd gotten hold of the type of object you
needed.  I seem to recall it turned out to be very challenging,
perhaps impossible, to come up with a complete system for this.  I'm
not sure if anyone is still working on it.  But it's an interesting
area.

> It's really just trying to provide a flexible interface though.
>
> Given that, I'm changing my answer.
>
> This is a documentation problem.  As long as the documentation tells me 
> your method needs a put_stuff_in() and a pull_stuff_out() to work, tells 
> me what they will be passed, and *doesn't* type check, you support ALL 
> data structures.  I can always wrap Hash, RBTree, Integer, 
> JamesCustomDataVoid, or whatever in a trivial class implementing those 
> calls.
>
> Am I making sense yet, or do I just need to go to sleep now?

Definitely the former, and perhaps the latter too -- 'tis up to you
:-)  I'm also very tired, and feeling semi-coherent at best, but
enjoying the thread.


David

-- 
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)