Hi --

On Fri, 28 Jan 2005, Austin Ziegler wrote:

> Okay, so define an object's type. See, this is where things get
> complicated -- it's *hard* to pin down an object's type in a
> language as dynamic as Ruby. For some methods, I require that the
> object provided have #<< defined; for others it's something else. I
> have gone away from pre-checking this[1], and there's really no way
> that any sort of heuristic can be built for it, either -- at least
> not one that performs faster than just running the code.

Also, it's "ducks all the way down" -- in the sense that *nothing* can
actually substitute for running the code.  I know that most of the
examples that illustrate this are marginal at best:

    s = "hi"
    def s.upcase; "ha ha"; end

    ...

    puts s.upcase if s.respond_to?(:upcase) and s.is_a?(String) # ...

However, it's still true -- and, looking at it in a more optimistic
way, I find the possibilities of harnessing this kind of power quite
exciting.

This reminds me of my days as head of Photo Services at a museum in
New York City.  The issue always arose of whether or not to create a
complete index of all the negatives in all the file cabinets.  My
position was always: whatever it says in the index, the *only* way to
know whether we have a negative of a given work is to look in the file
cabinet.  I would never hire a photographer to shoot an object without
making that final check.  Therefore, the index would serve mostly as a
kind of unnecessary second skin to the negative collection itself, and
creating the index would not be worth the time it would take.


David

-- 
David A. Black
dblack / wobblini.net