There is the memoized with the internally declared Dictionary new as the cache and memoized using: cache There cache is known and the result is a block that does the caching thing. ([ :cacheKey| self getIssueCreateMetaWithExpandKeys: true ] memoizedUsing: self cache) value: #issueCreateMeta BlockClosure>>#memoizedUsing: cache "Provide a memoization block using the given cache. So one can tune by passing a LRUCache for instance" ^[ :x | cache at: x ifAbsentPut: [ self value: x ] ] Basically a shorthand for your recommendation. But I would have put a cull: instead of value: because sometimes, like in my case, there is no parameter, the only useful thing is the cacheKey. And it would be nice to have the :v1 :v2 :vn version with the cache key being made out of the combination + cull:cull:cull: Really, this is just a shorthand. This is nicer IMHO than having cache at:ifAbsentPut: all over. | cache factorial result | cache := LRUCache new maximumWeight: 3. factorial := 0. "avoid not-initialised warning when saving method source" factorial := [ :n | n = 1 ifTrue: [1] ifFalse: [(factorial value: n - 1) * n] ] memoizedUsing: cache. result := (1 to: 5) collect: factorial. Phil On Thu, Jan 26, 2017 at 1:36 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 26 January 2017 at 02:10, phil@highoctane.be <phil@highoctane.be> wrote:
Ah ah :-D
DynamicVariables are darker magic that this, right?
you mean like those that seaside using? it lives as long as session lives, and tied to session you are working in.. in early versions of seaside they were using exceptions to access session storage.. quite ineffective.. but it works. for that purpose it is much better to use process-specific variables, that live and die together with process that hosts them.. but has significantly better access timings. and since seaside allocates a separate process per session, that's perfect fit.
in any case, the concern about getting rid of volatile data is covered.. while with memoization, i don't see it. and that seems like a HUGE argument against using it, because it is more trouble in a long run than time saver when you just start using it everywhere.
Phil
-- Best regards, Igor Stasenko.