On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > My point is that I'm not trying to create a "bad rep", I'm just emphasizing > that it's easier/more useful to define interfaces as collections of generic > operations, because it makes the simple cases simple and powerful, and the > complex ones possible. Doing it the other way around makes all of the > cases more complex, and loses other capabilities. > > My use of the word "unnecessary" isn't a moral judgment of interfaces, it's > an argument about how best to layer the various concepts we want to > have. Interfaces aren't necessary for simple things, and it's better (IMO) > if we define them *in terms of* simpler things, because then people don't > have to learn about them unless they need something more complex. > > And if they need something more complex, it is also more likely (I believe) > that they will have more specialized needs. So, I intended to suggest that > if we just do the basics (operations) and allow others to define interface > frameworks atop that, then we can avoid overgeneralizing from insufficient > experience. However, in the expanded discussion it seems to me that you > have goals for additional abilities you'd like to see sooner rather than > later. > > What worries me about Java-style interfaces is that you can't split and > recombine them in arbitrary ways, without effectively decomposing them into > single-operation interfaces using multiple inheritance.
But that's a limitation of Java interfaces (and perhaps of Zope interfaces); it doesn't have to be a limitation of Python 3000 abilities. > At which point, > you just might as well have treated them as operations to start > with! Thus, taking an operation-based approach means there need not be a > concept of the "one true sequence interface", just the *default* sequence > interface. If my needs are more or less expansive than the default > "sequence" interface, I should be able to do something like (sequence.len, > sequence.iter) and recombine a new interface. I'm not sure I understand the significance of prefixing len and iter with "sequence." in your example. After all len and iter are globals. And a default interface will surely tend to become a de-facto standard. What's your view on the interfaces for numbers and strings? I really don't think it's very useful to care much about objects that implement + and * but not / or ** -- while mathematicians have tons of use cases for those, programmers rarely do. As long as those mathematicians can create their own interfaces and apply them to the standard types they should be happy; the rest of us will be served well by a simple hierarchy e.g. Number, Complex, Real, Integer. Even more so for strings; I expect that a single String interface would cover most uses. Well, perhaps there ought to be something more basic representing the shared operations of strings and bytes. But that's about it. Container and file types are a different story; there are many partial reimplementations of the basic patterns and it is useful to be able to describe fairly minimal custom interfaces composed of a small number of operations. User-defined types are different again. I've recently had the opportunity to think a bit about refactoring a library that works with Perforce changelists (CLs; Perforce is a commercial source control system) to be generalized into supporting Subversion revisions. There are a lot of operations one can do on a Perforce CL objects. There is a lot of code that receives, produces or passes around Perforce CL objects. Some of this generalizes to Subversion; some of it doesn't. But I don't expect I'll be needing more than three interfaces to describe the eventual refactoring: an abstract source control revision class as the base interface, and two subclasses specializing for Subversion and Perforce. Sure, eventually someone will want to support CVS, or RCS, or (more likely) git or Mercurial or what have you. The code will continue to evolve and be refactored. But I don't think at any point I'll need to break my interfaces up into individual operations. > This would also make the interface committee's job at least somewhat > easier. :) Anything to make their job easier. I guess we'll have to lock them (us? :-) up in a room for several days before/after PyCon. -- --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
