On Mar 2, 2007, at 2:31 PM, dblack / wobblini.net wrote:
> The question, though, is whether it's possible to come up with a
> semantically rich way of reflecting on the type of a Ruby object.
> It's not a static-vs.-dynamic thing; static checking wouldn't enter
> into it.  It's more a question of having something that would do what
> people think class-checking does before they realize that it doesn't,
> if you see what I mean :-)  It may well not be possible.

I think that a consistent and well-known naming protocol gets you
pretty far down the road.  David, consider your example:

   def m(x)
     x << "string"
   end

The only reason that this is useful at all is that there are some
generally agreed upon semantics for methods named '<<'.  It may be
that for some objects Mystery#append does the same thing but that
isn't as useful within the Ruby ecosystem as the exact same method
named '<<' instead.

The well-known but not-actually-enforced rules for '<<' aren't universal
of course.  Sometimes '<<' means 'shift' rather than 'append'.  But
that alternate view is useful within its own subset of the Ruby
ecosystem.  The fact that the two views are mutually exclusive is OK
because a human is generally making sure that in any particular context
only one view or the other is being assumed.

I guess my point, which certainly isn't original, is that a consistent
naming methodology can often be a substitute or proxy for semantics.
Instead of declaring semantics via some sort of machine readable formal
language we cheat and intuit semantics from the patterns of syntax
created by the naming methodology.

Gary Wright