From: Geoff Youngs <g@...>
Date: 2003-11-21T10:53:21+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

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.

> I don't like it because it's an empty promise.

Until I know that Object (or Foo, elsewhere, for that matter) hasn't had
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
promise"... ;)

>   class Foo
>     interface IO
>   end

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

Then allow interface to check for required methods.

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

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

I don't follow.  If I write a library which operates on or with a
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 documentation
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
classes.

TTFN,


Geoff.