> I would actually hope that library implementors would shift to using > generic functions, since then they can just document what the function(s) > are supposed to do, and people can just add methods to those functions for > any object types they like, without needing to subclass anything, or have > to deal with "interfaces" at all.
I've got sympathy for this point of view, too (the Lispier the better, IMO), particularly for libraries. But note that this still means that people need to talk about "object types", and I think adding interfaces gives us a language for doing that. Remember that the Lisp object system was GF-based because Lisp was already a function-based language, and the GF system (which I regard as very ingenious) fit nicely into the existing framework. I think that shifting Python to a truly GF-based language would be a more radical change, since it has a strongly OO orientation right now (invoking methods on objects). Even GFs don't solve all invocation problems; in Lisp there was a lot of trouble in trying to retrofit the signature for a method for an existing GF into the existing definition. In essence, the inheritance issue with ABCs becomes a signature issue with GFs, only you have it with each function instead of with each type. And adding GFs does not give us a coherent ability to do type introspection, which I think would help. Again, I seem to need to look at values *returned* from calls as much as I worry about the type of parameters passed into my functions. GFs wouldn't help me there, would they? Bill _______________________________________________ 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
