[Israel.pm] Exporting a Memoized function

Gaal Yahas gaal at forum2.org
Thu Jun 27 08:00:12 PDT 2013


Maybe you can, but at that point you're really adding more requirements
than what Memoize.pm was designed for. For example: how do you prevent your
on-disk cache from growing indefinitely? Do you want any warmup queries
when your program starts in production, so that the data is partially in
RAM? And so on. It may be better to just add some mediator in between the
client code and the computation.

Memoize is really cool, but it's essentially just sugar for

{
my %cache;
sub f {
  my $key = cache_key(@_);
  return $cache{$key} if exists $cache{$key};
  # read f
  $res = ...
  $cache{$key} = $res;
  return $res;
}
}

Don't be afraid of using something else if you need something else.




On Thu, Jun 27, 2013 at 4:40 PM, Shmuel Fomberg <shmuelfomberg at gmail.com>wrote:

> On Thu, Jun 27, 2013 at 8:26 PM, Gaal Yahas wrote:
>
>> Wouldn't putting the call to memoize in a BEGIN block do the trick?
>>
>
> Ah, it will. But I want to expose the ability of tying the cache to a
> permanent storage (such as DB_File)  in production or not to, in testing
> mode.
>
> Which brings me to a new question: I connect the memorized function to a
> hashref that points to a tied hash that is tied to DB_File.
> Can I tie the hash afterwards? I think that I can.
> This will solve my memorize problem (that I already solved using one more
> function call) and will let me init the the permanent storage on run time.
> I like it.
>
> Shmuel.
>
> _______________________________________________
> Perl mailing list
> Perl at perl.org.il
> http://mail.perl.org.il/mailman/listinfo/perl
>



-- 
Gaal Yahas <gaal at forum2.org>
http://gaal.livejournal.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.perl.org.il/pipermail/perl/attachments/20130627/988ca253/attachment.htm 


More information about the Perl mailing list