s/read f/real f/
On Thu, Jun 27, 2013 at 6:00 PM, Gaal Yahas <[email protected]> wrote: > 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 > <[email protected]>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 >> [email protected] >> http://mail.perl.org.il/mailman/listinfo/perl >> > > > > -- > Gaal Yahas <[email protected]> > http://gaal.livejournal.com/ > -- Gaal Yahas <[email protected]> http://gaal.livejournal.com/
_______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
