[Python-Dev] PEP 246: lossless and stateless

[Bob Ippolito]

On Jan 14, 2005, at 19:02, Glyph Lefkowitz wrote:

> On Fri, 2005-01-14 at 10:07 -0500, Phillip J. Eby wrote:
>
>> Maybe I'm missing something, but for those interfaces, isn't it okay 
>> to
>> keep the state in the *adapted* object here?  In other words, if 
>> PointPen
>> just added some private attributes to store the extra data?
>
> Here's another example: I have a business logic class which lives in an
> object database, typically used for a web application.  I convert this
> into a desktop application.  Now, I want to adapt IBusinessThunk to
> IGtkUIPlug.  In the process of doing so, I have to create a GTK widget,
> loaded out of some sort of resource file, and put it on the screen.  I
> have to register event handlers which are associated with that adapter.
>
> The IBusinessThunk interface doesn't specify a __dict__ attribute as
> part of the interface, or the ability to set arbitrary attributes.  And
> nor should it!  It is stored in an indexed database where every
> attribute has to be declared, maybe, or perhaps it uses Pickle and
> sticking a GTK widget into its representation would make it
> un-pickleable.  Maybe it's using an O/R mapper which loses state that 
> is
> not explicitly declared or explicitly touch()ed.  There are a variety 
> of
> problems which using it in this unsupported way might create, but as 
> the
> implementor of a IGtkUIPlug, I should be concerned *only* with what
> IBusinessThunk provides, which is .embezzle()
> and .checkFundsAvailable().  I am not writing an adapter from
> DBBusinessThunkImpl, after all, and perhaps I am receiving a test
> implementation that works entirely differently.
>
> This example gets to the heart of what makes interfaces useful to me -
> model/view separation.  Although one might be hard pressed to call some
> of the things I use adaptation for "views", the idea of mediated access
> from a user, or from network protocol, or from some internal code 
> acting
> on behalf of a user is the overwhelming majority of my use-cases.

I think the idea is that it's "better" to have an adapter from 
IBusinessThunk -> IGtkUIPlugFactory, which you can use to *create* a 
stateful object that complies with the IGtkUIPlug interface.

This way, you are explicitly creating something entirely new (derived 
from something else) with its own lifecycle and state and it should be 
managed accordingly.  This is clearly not simply putting a shell around 
an IBusinessThunk that says "act like this right now".

-bob