From: Sean O'Dell <sean@...>
Date: 2003-11-20T09:05:36+09:00
Subject: Re: "stereotyping"

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.  In exceptional cases like half-implemented interfaces, 
you're going to get the same old errors you always got.  My feeling is, the 
higher the quality of object you have, the better your errors.  If you are 
inheriting from a well-developed class, it will implement the interface 
fully.  If you inherited from a class that was written by a guy who had to 
take a CompSci class on this way to earning an agricultural degree, you're 
probably going to see the old Ruby error you get when you pass a method an 
unsuitable object.

> Consider:
>
> Library A asks for interface "foo".
> Library B does trickery to pretend to provide it, but only sorta
>           does so.
> Programmer C uses Library B, only *oops* Library B forgot to
>              implement one method that A needs, so hey, we're right
>              back to status quo.

Perhaps comment in the RCR that you don't think interfaces should carry 
through inheritance.  I feel they should.

> 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?

> Honestly, I think 90% of what bugs me about Ruby library interfaces
> would be fixed if RDoc would dump formatted data somewhere useful, the
> way perldoc does.  That way, you just type 'man <class>' or at least
> 'rdoc <class>' (or whatever, I'm not trying to suggest a specific
> implementation here), and the class' requirements are there for all to
> see.  This works well for Perl modules, and I think it'd work equally
> well for Ruby.

But extensions written in C would be tricky.  I don't think just fixing the 
documentation mechanism is all there is to this.  To me, the issue isn't 
precise documentation as much as just getting a heads up most of the time 
when I've bad an unsuitable object to a method.

	Sean O'Dell