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

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

Christopher Barber wrote:
> It is not useful enough because you can enforce the extra level of
> strictness pretty easily merely by programming convention.
...
> Sure, but Curl already has "interfaces" in the form of classes and other
> static type declarations.  It just don't use the actual word "interface".
>
> > It seems reasonable - and actually quite important - to require a
> > declaration more like:
> >
> > >    {define-class Mutex implements Lockable
>
> How does this differ from inheriting from an abstract class, which Curl
> already supports?

I've pointed out myself that abstract classes and MI can be used to achieve
what I'm talking about.  The problem is that in practice, the distinction
between classes and interfaces, and between interface inheritance and
implementation inheritance, tends not to be widely understood.  When
programmers conflate these concepts, which happens regularly with
traditional OO languages that don't make these distinctions clear, the
result is sub-optimally factored designs, which limits reusability of code
and the flexibility of systems.  My experience has been that convention
alone isn't enough to prevent this.

I'm suggesting that making the distinction explicit in the language benefits
everyone - including the language designers, since their users will write
better code with the language as a result.  I can't prove that, but I can
offer Java as a success story in this area.  Making this distinction clear
is a best-practices kind of feature which is especially useful in a
corporate environment - and thus to me, seems relevant to a language like
Curl.

> > 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.
>
> That is what I am suggesting.  I have mixed feelings about it, but many
> would argue this is a useful concept.

On this point, I would argue on the "not useful enough" side.  You can use
'any' to achieve this, and it's probably better if you do, since use of
'any' serves to flag the looseness of the operation.  If a declaration like
"l:Lockable" simply means "check that l happens to include the methods in
the Lockable interface", the declaration gives a misleadingly strong
impression that some kind of agreed-upon contract is being satisfied, when
it isn't necessarily.

Still, something like this could make sense as part of a richer type
assertion language, which might allow fairly arbitrary type checking
operations to be specified for compile-time checking, if possible, or
runtime checking otherwise.  That could allow type assertions like this
(using Lispish syntax):

	; traditional strong interface assertion
	; x must explicitly support the Lockable interface:
	(supports-interface x Lockable)

	; weaker form of assertion, less safe
	; x must support a particular set of methods:
	(supports-methods x (lock unlock))

	; weaker assertion based on interface
	; x must support the methods of the Lockable interface,
	; even if x isn't explicitly specified to implement Lockable
	(supports-methods x (methods-of Lockable))

Note in the middle example, I haven't addressed the issue of signatures for
methods, other than their name, but that could of course be added.

I would want my editor or code analyzer to flag occurrences of
'supports-methods' in blinking bold red, though!

Anton