[Python-Dev] type categories

[Kevin Jacobs]

[I'm just jumping into this thread -- please forgive me if my reply does not
make sense in the context of the past discussions on this thread -- I've
only had time to read part of the archive.]

On Thu, 15 Aug 2002, Oren Tirosh wrote:
> In C a pointer and a value are both "objects".  But Python references are 
> not objects.

References are so transparent that you can treat them as 'instance
aliases'.

> In a language where almost everything is an object they are a 
> conspicous exception.

What semantics do you propose for "reference objects"?

> A slot in a list is bound to an object but there is no introspectable
> object that represents the slot *itself*.

Of course there is -- slots bind a memory location in an object via a
descriptor object stored in its class.

> And yes, sharing semantics make a big difference. My basic distinction is
> that type categories are not a property of objects.

Why not deconstruct these ideas a little more and really explore what we
want, and not how we want to go about implementing it.  Let us consider the
following characteristics:

  1) Static interfaces/categories vs. dynamic interfaces/categories?

  i.e., does a particular instance always implement a given interface or
        category, or can it change over the lifetime of an object (to to
        state changes within the object, or changes within the
        interface/category registry system).
        
  2) Unified interface/category registry vs. distributed interface/category
                                          registry?

  i.e., are the supported interfaces/categories instrinsic to a class or are
        they reflections of the desires of the code wishing to use an
        instance?  For example, there are many possible and sensible subsets
        of the "file-like" interface.  Must any class implementing
        "file-like" objects know about and advertize that it implements a
        predefined set of interfaces?  Or, should the code wishing to use
        the object instance be able to construct a specialized
        interface/category query with which to check the specific
        capabilities of the instance?

  3) (related) Should interfaces/categories of a particular class/instance
     be enumerable?

  4) Should interfaces/categories be monotonic with respect to inheritance?

  i.e., is it sufficient that base class of an instance implements a given
        interface/category for a derived instance to implement that
        interface/category.

  
> An object is what it is. It doesn't need "type checking". Type categories 
> are useful to check *references* and ensure that operations on a reference 
> are meaningful.

This distinction is meaningless for Python.  Objects references are not
typed, and thus any reference can potentially be to any type.  Putting too
fine a point on the semantic difference between the type of an object and
the type of an object reffered to by some reference is just playing games.

> A useful type checking system can be built that makes no 
> change at all to objects and type, only applying tests to references. The
> __category__ attribute I proposed for classes is not much more than a 
> convenient way to spell:
> 
> class Foo:
>     ...
> 
> assert Foo in category
> 
> The category is not stored inside the class. It is an observation about 
> the class, not a property of the class.

Given this description, I am guessing that these are your answers to my
previous questions:

1) dynamic, since your categories are not fixed at class creation
2) ?, either is possible, though I suspect you are advocating a standard
   unified category registry.
3) Yes, depending on implementation details
4) No

Please correct my guesses if I am mistaken.

Thanks,
-Kevin

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com