Re: caching mechanism and Re: PATCH Completion for _yum

[Bart Schaefer <schaefer@brasslantern.com>]

On Dec 13, 11:10am, Oliver Kiddle wrote:
}
} I'm also not keen on the functions setting a zstyle for the
} default cache policy. Couldn't the default just be a parameter
} to _cache_invalid? Some of the style lookups eschewed $curcontext so it
} is not making it easier to use right.

Using $curcontext would end up meaning that there are different copies
of the cache for different paths into the completion.  That's probably
not what's intended.

} The naming convention for these policy functions also doesn't help
} people to get the sense of the return status right. How about something
} like _finkpkgs_cache_stale instead of _finkpkgs_caching_policy?

To be honest I've always thought that the design of the caching system
was unnecessarily convoluted.  It's trying to be object-oriented and
template-like and probably mirrors something that was originally done
in another language in another context.  (Adam isn't still hanging
around here, is he?)

(This is somewhat ironic considering that the patch which proposed
the cache says "I think you'll agree the interface is very simple."
Two rounds of discussion with Sven W. later, ...)

It was also probably not the best idea to put the caching functions
in the doc in alphabetical order (or else they should have all been
named with _cache at the start instead of at the end); they should
have been in their own section with some explanation of the gestalt.