[Python-Dev] type categories
Mon, 26 Aug 2002 11:42:33 -0400
On Monday 26 August 2002 10:45 am, Guido van Rossum wrote:
> > Indeed. One of the advantages of separating inheritance and subtyping
> > is that this can give you a bit more flexibility in setting up the
> > ontology, which may make it easier to settle on something good.
> Really? Given that there are no inheritance relationships between the
> existing built-in types, I would think that you could define an
> ontology consisting entirely of abstract types, and then graft the
> concrete types on it. I don't see what having separate interfaces
> would buy you. But perhaps you can give an example that shows your
Several posts have expressed a need to support multiple ontologies for a given
set of classes. This doesn't preclude using the ontology that is defined by
the class hierarchy as one method for defining an ontology. That could be the
default ontology. What is missing is the ability to also place a class in to
an alternate ontology that may be specific to an application. The problem
could be solved if applications had the ability to add and delete references
to the type interface definition that apply to a class.
Perhaps the interface definitions should also be able to add themselves to
class definitions. That way common interface patterns that apply to standard
libraries could be defined in the standard library. This would eliminate the
repeated addition of interfaces to classes in each application.
Removing an interface from a class might not be possible, or it may require a
second class implementation to be created at compile time, because usage of
that interface may be required in some other module. I suspect having two
implementations of the same class might be somewhat confusing to the user.
Perhaps removal of a required interface would trigger an exception.