For the sake of argument, let's say that SegmentPen is a C type, which does not have a __dict__, and that PointPen is a Python adapter for it, in a different project.
There are multiple implementation alternatives possible here; it isn't necessary that the state be hidden there. The point is that, given the same SegmentPen, we want to get the same PointPen each time we *implicitly* adapt, in order to avoid violating the "naive" developer's mental model of what adaptation is -- i.e. an extension of the object's state, not a new object with independent state.
One possible alternative implementation is to use a dictionary from object id to a 'weakref(ob),state' tuple, with the weakref set up to remove the entry when 'ob' goes away. Adapters would then have a pointer to their state object and a pointer to the adaptee. As long as an adapter lives, the adaptee lives, so the state remains valid. Or, if no adapters remain, but the adaptee still lives, then so does the state which can be resurrected when a new adapter 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.
Anyway, as you and I have both pointed out, sticky adaptation is an important use case; when you need it, you really need it.
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.
If every time you pass a "model" to something that expects a "view", you get a new "view" instance being created, things are going to get mighty confusing, mighty fast. In contrast, explicit adaptation with 'adapt(model,IView)' or 'IView(model)' allows you to explicitly control the lifecycle of the view (or views!) you want to create.
Guido currently thinks that type declaration should be implemented as 'adapt(model,IView)'; I think that maybe it should be restricted (if only by considerations of "good style") to adapters that are sticky or stateless, reserving per-state adaptation for explicit creation via today's 'adapt()' or 'IFoo(ob)' APIs.
I wish I had a better suggestion, but I'm still struggling through the rest of the thread :).
I'll be starting work on the PEP soon, maybe I'll have a rough draft of at least the first few sections ready to post tonight so everybody can get started on ripping them to pieces. The sooner I know about the holes, the sooner I can fix 'em. Or alternatively, the sooner Guido shoots it down, the less work I have to do on the PEP. :)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
