On 11/22/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 09:42 AM 11/22/2006 -0700, Steven Bethard wrote: > >Yeah, it certainly seems like in both this case and the string case, > >there needs to be some shorthand for saying "implements all the basic > >String/Number/whatever methods". > > But we are probably better off composing such a concept *from* the methods, > rather than having the concept be merely a container *of* methods. > > This is basically the difference between Java interfaces and Haskell's > notion of "typeclasses". You can define typeclasses like "ordered" or > "four-function arithmetic" and it's okay if they overlap, because they're > defined in terms of the operations you can perform. So nothing prevents > somebody else from making "six-function arithmetic", or "reversible > strings" or whatever. And nobody has to *re*define their type as > supporting these new "interfaces", as long as they have the requisite > operations. > > So, if we have to have something like an interface, let's steal Haskell's > version of the idea instead of Java's, because it involves a lot less > typing. :)
But the main thing that stands in the way of doing the right thing in Java is that all interfaces have to be declared when the class is defined. In *my* notion of abilities, this part being inspired by Zope interfaces, you can state after the fact that a particular class (which you didn't write) provides a given ability (which you didn't write either). I think it would also be great if we had "ability algebra" whereby you could state that a given ability A is composed of existing abilities A1 and A2, and every object or class that already has A1 and A2 will automatically be considered to have A. However, I do *not* want to go the way of duck typing here -- if an ability A claims that it is implemented by method foo(), and an object x has a foo() method but doesn't explicitly claim to have ability A (and neither does its class), then testing x for A should return false. I think this deviates from Haskell, which seems to be big on structural type equivalence (?). So I think Python needs to do its own thing here, to some extent. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
