[Python-Dev] PEP 246: lossless and stateless

[Phillip J. Eby]

At 08:03 PM 1/13/05 -0500, Clark C. Evans wrote:
>Ok.  I think we have identified two sorts of restrictions on the
>sorts of adaptations one may want to have:
>
>   `stateless'  the adaptation may only provide a result which
>                does not maintain its own state
>
>   `lossless'   the adaptation preserves all information available
>                in the original object, it may not discard state

'lossless' isn't really a good term for non-noisy.  The key is that a 
"noisy" adapter is one that alters the precision of the information it 
provides, by either claiming greater precision than is actually present, or 
by losing precision that was present in the meaning of the data.  (I.e., 
truncating 12.3 to 12 loses precision, but dropping the middle name field 
of a name doesn't because the first and last name are independent from the 
middle name).

Anyway, being non-noisy is only a prerequisite for interface-to-interface 
adapters, because they're claiming to be suitable for all possible 
implementations of the source interface.

'statelessness', on the other hand, is primarily useful as a guide to 
whether what you're building is really an "as-a" adapter.  If an adapter 
has per-adapter state, it's an extremely good indication that it's actually 
a *decorator* (in GoF pattern terminology).

In GoF, an Adapter simply converts one interface to another, it doesn't 
implement new functionality.  A decorator, on the other hand, is used to 
"add responsibilities to individual objects dynamically and transparently, 
that is, without affecting other objects."

In fact, as far as I can tell from the GoF book, you can't *have* multiple 
adapter instances for a given object in their definition of the "adapter 
pattern".  IOW, there's no per-adapter state, and their examples never 
suggest the idea that the adapter pattern is intended to add any 
per-adaptee state, either.

So, by their terminology, PEP 246 is a mechanism for dynamically selecting 
and obtaining *decorators*, not adapters.  As if people weren't already 
confused enough about decorators.  :)

Anyway, for type declaration, IMO statelessness is the key criterion.  Type 
declaration "wants" to have true adapters (which can maintain object 
identity), not decorators (which are distinct objects from the things they 
add functionality to).


>In other words, while calling adapt directly would allow for any adapter;
>using the 'Static Typing' short-cut one would be asking for adapters
>which are both stateless and lossless.  Since __conform__ and __adapt__
>would sprout two new arguments, it would make those writing adapters
>think a bit more about the kind of adapter that they are providing.

Unfortunately, in practice this will just lead to people ignoring the 
arguments, because 1) it's easier and 2) it will make their code work with 
type declarations!  So, it won't actually produce any useful effect.