From: Chad Fowler <chad@...>
Date: 2003-11-20T09:23:56+09:00
Subject: Re: "stereotyping"

On Thu, 20 Nov 2003, Sean O'Dell wrote:

# On Wednesday 19 November 2003 03:57 pm, Eric Schwartz wrote:
# > "Sean O'Dell" <sean@celsoft.com> writes:
# > > It's a LOT better.  For you, who knows the contract, no, it's the
# > > same thing.  For a person using the library trying to pass in an
# > > unsuitable object, where the documentation is lacking (and that's
# > > MOST of the code out there, MOST code is completely undocumented) it
# > > results in an extremely useful and time-saving error message.
# >
# > It's not a lot better to me, because it's inconsistent.  If, as you
# > propose, it should work one way in some cases (the person honors the
# > interface) and not in others (they don't), then you're right back
# > where you started!
# 
# That's just how Ruby is, though.  When you get an object, you never know what 
# you're going to get with it.  It's completely open-ended.  This is just one 
# way to clear the air.

But what Eric is correctly saying is that this doesn't clear the air.  It 
pollutes it with potential lies.

To Glenn Vanderburg's point, objective-c does interface checking in a way 
that actually checks the interface--by grouping selectors into something 
called an interface and then creating code that requires that the 
*selectors are implemented*.  This "interface Blah" idea you've proposed 
isn't any better than checking for class, which I believe 99.9+% of us 
believe does *not* guarantee an interface at all.

Classes and modules are convenient groupings of behaviors.  They are 
neither declarations nor contracts that guarantee that such behaviors will 
persist in the objects that inherit from/include them.

# 

# > Only it's worse, because now Programmer C sees that B promised to
# > implement interface 'foo', and now she has to figure out where
# > interface 'foo' is defined (probably in Library D, which she may not
# > even have installed) and is even more confused than before.  And I
# > speak as someone who is continually irritated by having to troll
# > through, say, cgi.rb or dbi.rb to discover there's a method that does
# > what I want it to.
# 
# How does Ruby work right now?  Better than that?

Yes.  Because objects don't lie about what their capabilities are.  They 
either respond_to? or they don't.  class, module, or your "interface" have 
nothing to do with the "contract" of the object.