[Python-3000] iostack and Oh Oh

[Neil Toronto]

Guido van Rossum wrote:
> That sounds like a reasonable summary to me. One nit below.
>   

Ditto. It was nice to see all the ambiguity cleared up in one fell 
swoop. Nicely done.

> On 12/7/06, Talin <talin at acm.org> wrote:
>   
>> [2] The reason I think 'interface' are misleading is due to its Java
>> connotations, in which an interface is a description of a bunch of
>> methods as well as a signal of an abstract type, but in this case I
>> think what they want is *only* the contract signal and not the method
>> declarations.
>>     
>
> I don't see it this way. The methods are part of the contract -- the
> contract talks about specific methods *and* how they work together. I
> still believe this is also what Java interfaces are for, at least in
> the best of circumstances, like the collections framework (maybe I
> should ask Josh Bloch about this).

In most circumstances that's correct. An interface generally connotes 
some kind of behavior, often very specific, and sometimes even spelled 
out in detail in the interface's Javadoc. Here's an example from 
interface Comparable<T>:


This interface imposes a total ordering on the objects of each class 
that implements it. This ordering is referred to as the class's natural 
ordering, and the class's compareTo method is referred to as its natural 
comparison method.

Lists (and arrays) of objects that implement this interface can be 
sorted automatically by Collections.sort (and Arrays.sort). Objects that 
implement this interface can be used as keys in a sorted map or elements 
in a sorted set, without the need to specify a comparator.

The natural ordering for a class C is said to be /consistent with 
equals/ if and only if (e1.compareTo((Object)e2) == 0) has the same 
boolean value as e1.equals((Object)e2) for every e1 and e2 of class C. 
Note that null  is not an instance of any class, and e.compareTo(null) 
should throw a NullPointerException even though e.equals(null)  returns 
false.

It is strongly recommended (though not required) that natural orderings 
be consistent with equals. This is so because sorted sets (and sorted 
maps) without explicit comparators behave "strangely" when they are used 
with elements (or keys) whose natural ordering is inconsistent with 
equals. In particular, such a sorted set (or sorted map) violates the 
general contract for set (or map), which is defined in terms of the 
equals  method.


So when you write a method that takes a Comparable<T>, you're generally 
free to assume that 1) its compareTo() defines a total ordering, and 2) 
its compareTo() and equals() are consistent with each other. Other 
examples of interfaces having semantic meaning are littered throughout 
the API. But most of the time the behavior is implicit because the 
author of the interface was too lazy to spell out how classes 
implementing an interface are expected to behave, or assumed it would be 
clear from the method signatures.

My experience is limited mostly to collections, Swing, and database 
APIs, but from what I've seen, interfaces nearly *always* connote behavior.

Neil