[Python-3000] iostack and Oh Oh (original) (raw)

Neil Toronto ntoronto at cs.byu.edu
Thu Dec 7 20:26:45 CET 2006


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:

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, 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



More information about the Python-3000 mailing list