On Fri, Nov 21, 2003 at 09:21:42AM +0900, Austin Ziegler wrote:> On Fri, 21 Nov 2003 08:07:34 +0900, Weirich, James wrote:> > I haven't decided whether I like this or not. Right now I'm kinda
> > neutral. It avoids the problem of decreased flexibility at the cost
> > of an extra line of code.Until I know that Object (or Foo, elsewhere, for that matter) hasn't had> I don't like it because it's an empty promise.
method_missing redefined to catch read(bytes) and do something sensible
with it self.kind_of?(Foo), I can't declare the below to be an "empty
> class Foo
> interface IO
> endThen allow interface to check for required methods.> Now, if I try to use Foo somewhere, I've promised that it can do IO --
> but it can't. I haven't implemented any of the methods required to do
(And IMNSHO, IO would be a useless interface - it's far too broad for at
least 80% of cases. It should be broken down into at least
IOStreamRead, IOStreamWrite, IOStreamSeekable and possibly more.
Although interface combinations might be useful.)
I don't follow. If I write a library which operates on or with a> It also doesn't get us any closer to the concept of signature
> metadata, which despite my misgivings about wanting "contractual
> obligations", I believe Ruby needs for exposing programs to
> non-dynamic languages over wire protocols.
complex (ie. non-built in type), then I need to define how this complex
object should behave in terms of required methods. The best mechanism I
have seen anywhere in any language for doing this is an interface.
However traditional interface constraints (as per staticly typed
languages) might limit usefulness of such a feature in a language as
dynamic as Ruby, so a softer (probably runtime) approach would be more
in keeping with existing language features and checks.
That said, in the interests of programmers who use irb for doentation
and reflection in general, it is also highly desirable for the
expectations and provisions of an interface to queryable from Ruby code.
And it does get us closer - not all the way to a C function declaration,
but closer to a workable and rubyish contractual obligation between