"Sean O'Dell" <sean / celsoft.com> writes:
> On Wednesday 19 November 2003 03:57 pm, Eric Schwartz wrote:
>> 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.

Exactly!  And if you sorta-promise something, and you only
sorta-deliver on it, you get more confused than if you *know* you're
promised nothing.

>  It's completely open-ended. This is just one way to clear the air. 

But it doesn't clear the air, it only pretends to, and only in some
cases.

> In exceptional cases like
> half-implemented interfaces, you're going to get the same old errors
> you always got.

But with Ruby, it's not exceptional to only half-implement interfaces.
In fact, it's probably the default-- with duck typing, you only
implement enough to do the job.  I haven't seen enough other code to
know for sure, but I think you're being biased by your C++/Java
background to expect complete interface implementations more often
than no.

>> 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 at least right now Programmer C won't waste all that time
trying to figure out what 'foo' is, whether or not Library B
implemented all of it, and whether that's even relevant to the problem
at hand.  She'll dive right into library C's code and check it out,
which will save her much more time getting to the right answer.

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

They're not tricky in Perl right now, and they're used all the time.
Writing structured documentation isn't hard, and in fact, Perl
libraries have some of the best documentation I've found, regardless
of the languages they're written in.

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

If I get an error in a call to a library, be it C, Java, Perl, or
Ruby, the first thing I do is look up where in my code it happened,
and then check the documentation of the method or class I'm using at
that point, and see if it documents what the problem is.  Currently,
this is harder in Ruby than it needs to be, but when that's fixed,
there will be a relatively brief period of time where documentation
patches will be flying around left and right, and then it'll be a
doddle.

What you're asking for (currently) misses the spirit and attitude of
the language, so it's not surprising that people are reacting badly to
it.  You might just as well head over to comp.lang.python and tell
them that any sensible language wouldn't require significant
indentation, and create a PCR (or whatever it's called) to "fix" that.

-=Eric
-- 
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
		-- Blair Houghton.