Author pitrou
Recipients daniel.urban, lukasz.langa, ncoghlan, pitrou
Date 2013-05-25.15:57:48
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1369497460.2562.9.camel@fsol>
In-reply-to <1369496912.02.0.854233733047.issue16832@psf.upfronthosting.co.za>
Content
> I thought about that originally, but there's only ever one object
> graph for the process, and as soon as you break any one edge in that
> graph you pretty much invalidate anything based on caching traversal
> results.

Ah, I was forgetting that a ABC registration also affects the subclasses
of the registered class, and the abstract parents of the ABC class.
So it's a bit more annoying than it looked like.

> So it's not really an implementation detail, it's a promise to provide
> a unique token for the current state of the object graph that can be
> used reliably for cache invalidation.

Sounds fair.

> A callback based system is actually *harder* to use, because you can't
> simply ask the question "Is my cache still valid?" - you have to
> register a callback that sets a flag, or something similar. Your
> lookup code ends up being:

Well, the point of a callback based system is for the callback to
invalidate or recompute the cache *right now*, so you don't have to
"check a flag" each time you do a lookup.

It's a basic cost/benefit compromise: the callback system makes
invalidations more expensive, but lookups cheapers.

Besides, a callback-based system can be more future-proof than exposing
the raw cache tags or tokens.
History
Date User Action Args
2013-05-25 15:57:48pitrousetrecipients: + pitrou, ncoghlan, daniel.urban, lukasz.langa
2013-05-25 15:57:48pitroulinkissue16832 messages
2013-05-25 15:57:48pitroucreate