“Sean O’Dell” sean@celsoft.com writes:
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 ’ or at least
‘rdoc ’ (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
···
On Wednesday 19 November 2003 03:57 pm, Eric Schwartz wrote:
–
Come to think of it, there are already a million monkeys on a million
typewriters, and Usenet is NOTHING like Shakespeare.
– Blair Houghton.