Re: Thoughts on interfaces

Jonathan Gardner wrote:
> I've spent some time thinking on my own about interfaces. I'll try to
> sum up my thoughts and see how it ties into the class proposal.
>
> -- What are interfaces?
>
> Interfaces are a precise description of an object. They declare what
> an object provides - what attributes and methods, and the format of
> those attributes and methods.
>
> Interfaces are an answer to the problem of type(). When you are
> checking an object's type, you are usually asking "Do you give me the
> things I expect?" Only rarely are you asking for the actual type of
> the object (like in C extension modules.)
>
> -- Why do we want interfaces?
>
> In an untyped language like Prothon (where everything is an object),
> we don't have a way to specify that we are expecting an integer, a
> function, a thread, or even a particular kind of object. Instead, we
> write out what we need in comments or doc strings or documentation.
>
> The interfaces provide a sort of contract. Objects that comply with an
> interface are guaranteed to provide certain functions and attributes.
>
> -- How do we declare an interface?
>
> This is the complicated part. We first start with basic interfaces
> that define well-known types like bools, integers, strings, lists,
> and even "any object".
>
> Then we move onto more complicated and user-defined interfaces. These
> would include a list of what attributes are expected in the object,
> and the interfaces of those attributes. It would also contain a list
> of expected methods, the acceptable parameters to those methods, and
> the interfaces of those parameters.
>
> Interfaces do not exclude attributes or methods. For instance, you
> can't create an interface that says "This object does NOT provide
> this attribute or method".
>
> The syntax for declaring an interface would have to be something very
> different than anything we've seen in Python. I think something like:
>
> interface FooInterface:
> bar BarInterface
> int IntInterface
> def baz(bar BarInterface, int IntInterface, *args IntListInterface)
>
> Note that the IntListInterface is something you may recognize as being
> handled by "templates" in C++. We may want to provide a similar
> feature.
>
> interface FooInterface<a, b, c>:
> bar a
> baz ListInterface<b>
> def foobar(foo a, bar b, baz c)
>
> -- What can we do with an interface?
>
> Objects can claim to support an interface. They'll add the interface
> they implement to the list of "interfaces_".
>
> Objects can also be tested to see if they support an interface. If the
> interface to be tested against does not appear in the list of
> "interfaces_", then the interface is tested against the interfaces in
> "interfaces_". If there is an incompatibility, then the object cannot
> support that interface.
>
> If there are no incompatibilities, then the actual object itself can
> be tested. It would query for each attribute and method and see if the
> attribute or method defined conforms with the interface being tested.
>
> -- What would be the effect of having interfaces?
>
> This would be bringing in strongly typed features as an optional
> extension to Prothon. It should be noted that Zope and other python
> systems use an interface model.

---- replies from wiki ----

Serge:
This proposal doesn't discuss what happens when two interfaces must provide
two methods with the same name but different signatures. It also binds
interfaces with contracts right away. I believe interfaces in a dynamic
language should be defined without contracts first, then runtime contracts
can be added. My last attempt to describe contractless interfaces is here:
http://www.prothon.org/pipermail/prothon-user/2004-June/002324.html
I will move it to wiki today or tomorrow.

Jonathan:
If two interfaces must provide something with two different signatures -- 
provided those signatures are incompatible -- then those two interfaces are
incompatible.