I think what you are doing is analogous to the peek and pop operations in
core.
To get and remove and item you would peek to get the first item, and then
alter your ref with a pop, which returns the structure minus with the first
item removed.
If you do all of this within a dosync, including the
Peter Schuller peter.schul...@infidyne.com writes:
I can turn 'get' into 'peek' and have another function that more
specifically advertises, by its name, that it produces both a value
and a new cache. That only helps naming though, and not usability of
said function.
Yes, and though it does
Hello,
I wrote a persistent LRU cache, but I'm not sure I am satisfied with
the interface in particular (and perhaps the implementation). It's at:
http://github.com/scode/plru
git://github.com/scode/plru.git
(Btw in general I'd appreciate any feedback - especially negative
about the
Peter Schuller peter.schul...@infidyne.com writes:
lru-peak - [value]
I take it you meant peek, not peak.
[...]
One possibility I was thinking of was that, since the expected use
case of an LRU cache is so specific, it may be acceptable to have the
lru library itself provide a
lru-peak - [value]
I take it you meant peek, not peak.
Yes - Yes. How embarrassing ;) Thanks.
One possibility I was thinking of was that, since the expected use
case of an LRU cache is so specific, it may be acceptable to have the
lru library itself provide a side-effect aware interface
Another thing occurred to me: While not necessarily important in the
cache of an LRU cache, one might want a data structure, even if it
tends to be used in a side-effectful manner, to participate in STM
co-ordinated transactions. If one hides an underlying ref, this means
that either callers do
This might be of related interest:
http://kotka.de/blog/2010/03/The_Rule_of_Three.html
On Jul 17, 3:19 pm, Peter Schuller peter.schul...@infidyne.com
wrote:
Another thing occurred to me: While not necessarily important in the
cache of an LRU cache, one might want a data structure, even if it
