RE: Curl, multiple inheritance, and interfaces (was Re: cheerful static typing)

["Christopher Barber" <address@hidden>]

> Christopher Barber wrote:
> > Simply because we don't have time to design and implement
> everything that
> > could be useful!
>
> Sorry, I realize you don't have infinite development bandwidth.
> The point I
> was really making is that I think that saying MI implies "no need for
> interfaces" is too strong, and I was curious if Curl had some other reason
> to not require explicit interfaces.
>
> > That may be true, but I rather doubt that they would have bothered to
> > introduce the extra complexity of interfaces if they had retained full
> > multiple inheritance.
>
> If they hadn't, I'd be in there arguing for it!  ;)  Actually, it seems to
> me that in the presence of MI and abstract classes, an explicit interface
> feature doesn't add much extra complexity.  "Interface" can be a
> synonym for abstract class, ...

Curl does require that abstract classes be explicitly marked but does not
require abstract classes to only contain abstract methods.  We have
considered having a stricter version of this, but felt that it was not
useful enough to add to the language.

If we were to add a concept of an "interface", I would want it to be
divorced from class inheritance, so that an interface would be compatible
with any object that satisfies it.  For example, given the interface:

   {define-interface Lockable
      {method {lock}:void}
      {method {unlock}:void}
   }

and the class:

   {define-class Mutex
       ...
       {method {lock}:void}
       {method {unlock}:void}
   }

you could write:

   {define-proc {lock l:Lockable}:void
       {l.lock}
   }

   ...

   let my-lock:Mutex = {Mutex}
   {lock my-lock}

This is an improvement over use of 'any' in that use of the interface could
be checked at compile time.  However, unless the compiler can infer the
actual implemention type, a slower dispatch mechanism would have to be used.

- Christopher



- Christopher