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 <[email protected]> wrote:
>
>
> On 26 January 2017 at 02:10, [email protected] <[email protected]>
> 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.
>
