[Python-Dev] type categories
Thu, 15 Aug 2002 14:58:53 +0200
Oren Tirosh wrote:
> On Wed, Aug 14, 2002 at 10:08:59AM -0400, Andrew Koenig wrote:
> > 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".
Okay, but in Python interfaces as we know them (the Scarecrow descended
interfaces as in use in Zope 2 and Zope 3), you can say things like this
(with some current limitations concerning basic types). Usually however
one does use the __implements__ class attribute, but that's because it's
often clearer and easier when one is writing a new class.
> 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).
This is quite different from the Zope interfaces approach, I think.
Zope interfaces do talk about objects, not references. This is leaning
towards a more static feel of typing (even though it may be quite different
from static typing in the details), which I think should be clearly
marked as quite independent from a discussion on interfaces.
Though I'd still call your beasties Interfaces and not categories, even
though you want to use them in a statically typed way -- but please let's
not reject simple interfaces just because we may want to do something
complicated and involved with static typing later..