Guido> Well, yes, of course. But I strongly believe that in *most* cases,
Guido> inheritance and subtyping go hand in hand. I'd rather invent a
Guido> mechanism to deal with the exceptions rather than invent two parallel
Guido> mechanisms that must both be deployed separately to get the full
Guido> benefit out of them.
I think there are (at least) three important kinds of problems, not just two.
1) You want to define a new class that inherit from a class
that already exists, and you intend your class to be in all
of the categories of its base class(es). This case is
probably the most common, so whatever mechanism we adopt
should make it easy to write.
2) You want to define a new class that inherits from a class
that already exists, but you do *not* want your class to be
in all of the categories of its base classes. Perhaps you
are inheriting for implementation purposes only. I think
we all agree that this case is relatively rare--but it is
not completely unheard of, so there should be a way of
coping with it.
3) You want to define a new type category, and assert that
some classes that already exist are members of this category.
You do not want to modify the definitions of these classes
in order to do so. Defining new classes that inherit from
the existing ones does not solve the problem, because you
would then have to change code all over the place to make
it use the new classes.
Here is an example of (3). I might want to define a TotallyOrdered
category, together with a sort function that accepts only a container
with elements that are TotallyOrdered. For example:
def sort(x):
if __debug__:
for i in x:
assert i in TotallyOrdered # or whatever
# continue with the sort here.
If someone uses my sort function to sort a container of objects that are
not of built-in types, I don't mind imposing the requirement on the
user to affirm that those types do indeed meet the TotallyOrdered
requirement. What I do not want to do, however, is require that the
person making the claim is also the author of the class about which
the claim is being made.
Incidentally, it just occurred to me that if we regard categories
as claims about types (or, if you like, predicate functions with type
arguments), then it makes sense to include (Cartesian) product types.
What I mean by this is that the TotallyOrdered category is really a
category of pairs of types. Note that the comparison operators generally
work on arguments of different type, so to make a really appropriate
claim about total ordering, I really need a way to say not just that
a single type (such as int) is totally ordered, but that all combinations
of types from a particular set are totally ordered (or not -- recall that
on most implementations it is possible to find three numbers x, y, z
such that total ordering fails, as long as you mix int and float
with sufficiently evil intent).
--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4