[Python-3000] iostack and Oh Oh
janssen at parc.com
Fri Dec 1 22:41:23 CET 2006
> 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,
More information about the Python-3000