[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
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