>> 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 directly. > > The LRU aspect of the cache is no business of those using the "get" and > "put" parts of the interface. Those callers should just think they're > using an associative array, dictionary, map, or whatever you want to > call it. That having called "get" may influence what gets evicted next > from some other function isn't germane to the caller's interest. That would be exactly my reasoning when writing code in a language/style where implicit side-effects were kosher. > Unless you're willing to use something like the State monad to represent > (and help hide) the side effects of calling your "get" function, I think > you're better of making no claim about what "get" does beyond its normal > contract: promise only that it returns the value mapped to the given > key, if any. This data structure doesn't seem like a good fit for a > functional-style interface. 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. Assuming there is a legitimate need for a persistent data structure (such as for concurrent background introspection purposes), what would be your favored approach in terms of an interface? I could make an interface that works the way you would expect it to work in Java/Ruby/Python etc, hiding the side-effects. However that would also fail to expose the persistent aspect of it, unless I provide an accessor that gives the caller a persistent snapshot of the cache. The difference between that and my suggested side-effectful interface, it seems to me, is that while my first suggestion had the primary interface be functional but to provide a convenience interface that has side-effects, while this other variant would provide a side-effectful interface as its primary interface, but with the specific ability to produce a persistent snapshot. -- / Peter Schuller -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
