On Fri, Sep 10, 2010 at 11:41 PM, Gavin Panella <[email protected]> wrote: > Hi, > > Recently I landed the new propertycache API, which is a replacement > for the cachedproperty API (there is still a cachedproperty decorator, > but it lives in the propertycache module rather than cachedproperty). > > It uses adaption to get the cache object for the target: > > cache = IPropertyCache(target) > cache.a_cached_value = 1234 > > However, I had to hobble it at the last minute to only pretend to do > adaption (i.e. IPropertyCache is currently a plain function, not an > interface) because the adapters were not registered in several tests, > and so cached properties were breaking. See bug 628762 [1] for the > lowdown. > > The adapters are registered via ZCML *and* with the global site > manager, so I have no idea why they are sometimes not present. > > It already seems weird to register them both via ZCML and the global > site manager. If I just use ZCML a whole raft of tests fail. If I just > use ZCML a different raft of tests fails. > > I also can't replicate the problem without running the full test > suite.
This seems to draw a fairly large bow : adaption not working in one context -> don't use adaption anywhere. I think the declarative adaption facilities of the ZCA are great; but that adaption isn't a panacea : the boilerplate you described would be better written with delegation, not adaption. # Note that writing it this way makes it reasonably clear that we # aren't using delegation/composition as much as we could in this area. self.populateArgs() Similarly, I'm very unconvinced that using adaption for the property cache was useful or helpful. I like the new API, but it seems like it could be more pithy, more reusable and faster if it was just plain python. -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
