[Python-Dev] type categories

[Oren Tirosh]

On Wed, Aug 14, 2002 at 10:08:59AM -0400, Andrew Koenig wrote:
> >> The category names look like general purpose interface names. The
> >> addition of interfaces has been discussed quite a bit. While many
> >> people are interested in having interfaces added to Python, there
> >> are many design issues that will have to be resolved before it
> >> happens.
> 
> Oren> Nope. Type categories are fundamentally different from
> Oren> interfaces.  An interface must be declared by the type while a
> Oren> category can be an observation about an existing type.
> 
> Why?  That is, why can't you imagine making a claim that type
> X meets interface Y, even though the author of neither X nor Y
> made that claim?

It's not a failure of imagination, it's a failure of terminology. In
contexts where the term 'interface' is used (Java, COM, etc) it usually 
means something you explicitly expose from your objects. I find that the 
term 'category' implies something you observe after the fact without 
modifying the object - "these objects both have property so-and-so, let's 
group them together and call it a category".

> However, now that you bring it up... One difference I see between
> interfaces and categories is that I can imagine categories carrying
> semantic information to the human reader of the code that is not
> actually expressed in the category itself.  As a simple example,
> I can imagine a PartialOrdering category that I might like as part
> of the specification for an argument to a sort function.

You can define any category you like and attach a semantic meaning to it
as long as you can write a membership predicate for the category. It may
be based on a marker that the type must have or, in case you can't change
the type (e.g. a builtin type) you can write a membership predicate that
also tests for some set of specific types. 

> Oren> A category is defined mathematically by a membership
> Oren> predicate. So what we need for type categories is a system for
> Oren> writing predicates about types.
> 
> Indeed, that's what I was thinking about initially.  Guido pointed out
> that the notion could be expanded to making concrete assertions about
> the interface to a class.  I had originally considered that those
> assertions could be just that--assertions, but then when Guido started
> talking about interfaces, I realized that my original thought of
> expressing satisfaction of a predicate by inheriting it could be
> extended by simply adding methods to those predicates.  Of course,
> this technique has the disadvantage that it's not easy to add base
> classes to a class after it has been defined.

That's why the intelligence should be in the membership predicate, not in 
the classes it selects. Nothing needs to be changed about types. 
Conceptually, categories apply to *references*, not to *objects*. They help 
you ensure that during execution certain references may only point to 
objects from a limited category of types so that the operations you perform 
on them are meaningful (though not necessarily correct). A situation that 
may lead to a reference pointing to an object outside the valid category 
should be detected as early as possible. Detecting this during compilation 
is great. On module import is good. At runtime it's ok.

Can you can think of a better name than 'categories' to describe a set of 
types selected by a membership predicate? 

	Oren