I know this is used a lot (the weakref persistence stuff). Should it be option of adaptation or perhaps of adapter registration? Trying to see how to fit this in to zope3's, which doesn't do this, and it'd be nice to have it as part of their core code rather than ours. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html
Itamar Shtull-Trauring wrote:
It seems a lot saner to make it a part of registration than adaptation. The 'persist' argument to __call__ never made sense to me. Think about a what the objects involved "know": if an object knows that it wants an adapter and it wants it to persist, it can just keep a reference to the adapter it gets back. OTOH, we don't currently support marking an adapter persistent at registration time, do we? I say don't add features that don't have clear use cases yet. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com/
On Apr 22, 2004, at 7:04 PM, Itamar Shtull-Trauring wrote:
I'm not sure about 'used a lot', looks more like "used a bit". In any case, I don't know much about Zope3 interfaces but in PyProtocols you could implement a 'persist' functionality by registering a null adaptation from the 'original' instance to the 'persisted' adapter instance. And that could be controlled by the adapter itself (its __init__ could register the new adaptation on 'original') which makes more sense) or the caller. That of course doesn't act exactly the same as it doesn't have the weirdo persist=None vs persist=False behavior. Does anyone actually depend on that? The current persist argument API is completely bogus so I don't think it's a good idea to hack up Zope3's code just for backwards compatibility with our broken API. James
On Thu, 2004-04-22 at 19:39, James Y Knight wrote:
I'm not sure about 'used a lot', looks more like "used a bit".
OK. Can anyone describe or point at some of these use cases?
Oh, I wouldn't do *that*. But weakref persistence of adapters is a useful idea, and I'm going to have to have a backwards compat layer anyway. Question is what parts of it *are* useful and if so what API they should have. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html
Itamar Shtull-Trauring wrote:
It seems a lot saner to make it a part of registration than adaptation. The 'persist' argument to __call__ never made sense to me. Think about a what the objects involved "know": if an object knows that it wants an adapter and it wants it to persist, it can just keep a reference to the adapter it gets back. OTOH, we don't currently support marking an adapter persistent at registration time, do we? I say don't add features that don't have clear use cases yet. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | Release Manager, Twisted Project ---------+ http://radix.twistedmatrix.com/
On Apr 22, 2004, at 7:04 PM, Itamar Shtull-Trauring wrote:
I'm not sure about 'used a lot', looks more like "used a bit". In any case, I don't know much about Zope3 interfaces but in PyProtocols you could implement a 'persist' functionality by registering a null adaptation from the 'original' instance to the 'persisted' adapter instance. And that could be controlled by the adapter itself (its __init__ could register the new adaptation on 'original') which makes more sense) or the caller. That of course doesn't act exactly the same as it doesn't have the weirdo persist=None vs persist=False behavior. Does anyone actually depend on that? The current persist argument API is completely bogus so I don't think it's a good idea to hack up Zope3's code just for backwards compatibility with our broken API. James
On Thu, 2004-04-22 at 19:39, James Y Knight wrote:
I'm not sure about 'used a lot', looks more like "used a bit".
OK. Can anyone describe or point at some of these use cases?
Oh, I wouldn't do *that*. But weakref persistence of adapters is a useful idea, and I'm going to have to have a backwards compat layer anyway. Question is what parts of it *are* useful and if so what API they should have. -- Itamar Shtull-Trauring http://itamarst.org Looking for a job -- http://itamarst.org/resume.html
participants (4)
-
Christopher Armstrong -
Glyph Lefkowitz -
Itamar Shtull-Trauring -
James Y Knight