[Python-Dev] PEP 246: lossless and stateless

[Phillip J. Eby]

At 10:35 AM 1/15/05 +0100, Alex Martelli wrote:

>On 2005 Jan 15, at 02:30, Phillip J. Eby wrote:
>
>>is requested.  It's too bad Python doesn't have some sort of deallocation 
>>hook you could use to get notified when an object goes away.  Oh well.
>
>For weakly referenceable objects, it does.  Giving one to other objects 
>would be almost isomorphic to making every object weakly referenceable, 
>wouldn't it?  Or am I missing something...?

I meant if there was some way to listen for a particular object's 
allocation, like sticking all the pointers you were interested in into a 
big dictionary with callbacks and having a callback run whenever an 
object's refcount reaches zero.  It's doubtless completely impractical, 
however.  I think we can probably live with only weak-referenceable objects 
being seamlessly sticky, if that's a word.  :)

Actually, I've just gotten to the part of the PEP where I have to deal with 
stateful adapters and state retention, and I think I'm going to use this 
terminology for the three kinds of adapters:

* operations (no adapter class needed)

* extenders (operations + a consistent state that conceptually adds state 
to the base object rather than creating an object w/separate lifetime)

* "volatile", "inconsistent", or "disposable" adapters (state may be lost 
or multiplied if passed to different routines)

The idea is to make it really easy to make any of these, but for the last 
category you should have to explicitly declare that you *want* volatility 
(or at least that you are willing to accept it, if the target type is not 
weak-referenceable).

In this way, all three kinds of adaptation may be allowed, but it takes one 
extra step to create a potentially "bad" adapter.  Right now, people often 
create volatile adapters even if what they want is an extender ("sticky 
adapter"), because it's more work to make a functioning extender, not 
because they actually want volatility.

So, let's reverse that and make it easier to create extenders than it is to 
create volatile adapters.  And, since in some cases an extender won't be 
possible even when it's what you want, we could go ahead and allow type 
declarations to make them, as long as the creator has specified that 
they're volatile.

Meanwhile, all three kinds of adapters should avoid accidental implicit 
transitivity by only adapting the "original object".  (Unless, again, there 
is some explicit choice to do otherwise.)  This makes the type declaration 
system a straightforward extension of the COM QueryInterface and Java 
casting models, where an object's "true identity" is always preserved 
regardless of which interface you access its operations through.