Declaratively caching results of a method

ruby-talk
1

Alrighty, then. I'll make that change in the next release.

Thanks, all, for the input!

Dan

···

-----Original Message-----
From: Sean O'Halpin [mailto:sean.ohalpin@gmail.com]
Sent: Monday, October 17, 2005 4:05 PM
To: ruby-talk ML
Subject: Re: declaratively caching results of a method

On 10/17/05, Ryan Leavengood <leavengood@gmail.com> wrote:
> On 10/17/05, Daniel Berger <Daniel.Berger@qwest.com> wrote:
> >
> > I'm debating between this suggestion and Pit's (where you
access the
> > cache via it's name and as an instance method). I dunno
- what do
> > people prefer?
> >
> > This one is certainly simpler :slight_smile:
>
> I prefer Pit's. Otherwise you'll have to hang on to each cache
> yourself (should you memoize several methods), instead of
just letting
> the class do it.
>
> Ryan

Agreed. Pit's is better (even if more complicated :wink:

Sean

2

Berger, Daniel schrieb:

(accessing the memoize cache)

Alrighty, then. I'll make that change in the next release.

My code was meant as a quick hack for the OP to be able to experiment with the cache. I wouldn't include it in the library, though, because I don't like polluting the namespace with those additional methods.

What are the use cases for accessing the cache? (I remember someone talking about filling it with predetermined values.)

Maybe there are other ways to implement the desired functionality.

Regards,
Pit