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.