launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Fri, Sep 10, 2010 at 11:41 PM, Gavin Panella
<gavin.panella@xxxxxxxxxxxxx> 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