RE: Curl, multiple inheritance, and interfaces

["Anton van Straaten" <address@hidden>]

Kragen Sitaker wrote:
> Zooko writes:
> >  "Anton van Straaten" <anton@appsolutions.com> wrote:
> > > If you're suggesting that simply because a class happens to include
> > > methods that match a particular interface, that it should satisfy
> > > that interface, I don't think that's a very good idea.  It is what
> > > Smalltalk-like languages effectively do, though, but that's only
> > > because they're not being explicit about interfaces at all, and
> > > because they only support single inheritance so are forced to
> > > "cheat" to support multiple interfaces on an object.
> >
> > When I switched to programming in Python instead of C++ and Java, I
> > learned this style of interfaces, and quickly grew to love it.  I
> > can't speak for the designers of Smalltalk, but if I design my own
> > programming language, it will definitely include this style of
> > dynamic, structural typing as a feature -- not as a work-around for
> > some other inadequacy.  ;-)
>
> I agree.  I often wish it were a little more explicit, though --- in
> documentation, if nowhere else.  It's often hard to figure out what
> methods you need to implement to make an object acceptable to some
> piece of code.

This is my problem with it, also.  In dynamically-typed class-based OO
languages, you explicitly identify classes, so there's both documentation
and manifestation in code of the kind of type that corresponds to a class,
i.e. a class is a type.  However, once you introduce ad-hoc interfaces, you
have types that are never identified in the program code, and can only be
identified based on their usage, or in documentation.

My point is not that static typing is essential - I'm a big fan of dynamic
typing myself.  However, I don't like having no alternative to ad-hoc
interfaces (I refuse to dignify them with the name "structural typing", so
there! :)  As SmallScript apparently demonstrates, it's possible to retain
dynamic typing but still allow explicit identification of interfaces.

Anton