That sounds like a reasonable summary to me. One nit below. On 12/7/06, Talin <[EMAIL PROTECTED]> wrote: > Phillip J. Eby wrote: > > At 09:59 AM 12/5/2006 -0600, Guido van Rossum wrote: > >> My point is that an interface can *document* (at least in English) a > >> "contract" about the invariants between operations. While I'm not into > >> enforcing or verifying such contracts, I'm very interested in > >> documenting them. For example, something that has "mapping" behavior > >> has a very different relationship between x[y] and "y in x" than > >> something that has "sequence" behavior. > > > > I assumed this didn't need answering. If you're using the interface solely > > for documentation, then a namespace-oriented interface suffices to provide > > it. > > I'm guessing that Guido's use of the word 'document' means something > more than just conveying information to a human reader. > > From what I can tell, the argument boils down to this: You are saying > that a class is merely the sum of its attributes and methods, and Guido > is saying that it's not. > > For example: You cannot deduce by examining the methods of a list that > the keys are required to be consecutive integers starting from 0. Lists > have __getitem__, but so do maps; They support len(), but so do maps; > and so on. > > Thus, lists embody a particular behavior contract (called 'concept' in > C++ template land). (The word 'interface' and 'ability' has been used in > this context, but that's somewhat misleading. [1] [2]) The concept is > supported by the methods of the class, but is only incompletely > derivable from them. > > I think what Guido is looking for is a way to signal that a class obeys > a given behavioral contract, and a way to inspect the object, both at > runtime *and* to a human reader, and discover what contracts are > supported by the class. > > On the other side of the argument is the fear that such explicitness > will lead to Java-style type bureaucracy, and lead to the death of > implicit, a la 'duck', typing. > > The response to that, I think, is that we're not looking to replace duck > typing but only to supplement it - in other words, this extra > information would only be used to convey that which is not derivable by > inspection of types and methods. > > [1] The reason that I think 'ability' is misleading is because what > we're really talking about is a *disability* - a limitation on what > inputs a class can accept. Also, one tends to think of the abilities of > a class as its methods, whereas what we're talking about here is a way > to describe the relationships *between* the methods. > > [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). -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
