# Version 0.05 alpha $Revision: 1.4 $ $Date: 1998/09/07 19:48:43 $
=head1 TO DO
=over 4
=item *
We should extend the benchmarking module to allow
timethis(main, { MEMOIZED => [ suba, subb ] })
What would this do? It would time C<main> three times, once with
C<suba> and C<subb> unmemoized, twice with them memoized.
Why would you want to do this? By the third set of runs, the memo
tables would be fully populated, so all calls by C<main> to C<suba>
and C<subb> would return immediately. You would be able to see how
much of C<main>'s running time was due to time spent computing in
C<suba> and C<subb>. If that was just a little time, you would know
that optimizing or improving C<suba> and C<subb> would not have a
large effect on the performance of C<main>. But if there was a big
difference, you would know that C<suba> or C<subb> was a good
candidate for optimization if you needed to make C<main> go faster.
Done.
=item *
Perhaps C<memoize> should return a reference to the original function
as well as one to the memoized version? But the programmer could
always construct such a reference themselves, so perhaps it's not
necessary. We save such a reference anyway, so a new package method
could return it on demand even if it wasn't provided by C<memoize>.
We could even bless the new function reference so that it could have
accessor methods for getting to the original function, the options,
the memo table, etc.
Naah.
=item *
The TODISK feature is not ready yet. It will have to be rather
complicated, providing options for which disk method to use (GDBM?
DB_File? Flat file? Storable? User-supplied?) and which stringizing
method to use (FreezeThaw? Marshal? User-supplied?)
Done!
=item *
Maybe an option for automatic expiration of cache values? (`After one
day,' `After five uses,' etc.)
=item *
Put in a better example than C<fibo>. Show an example of a
nonrecursive function that simply takes a long time to run.
C<getpwuid> for example? But this exposes the bug that you can't say
C<memoize('getpwuid')>, so perhaps it's not a very good example.
Well, I did add the ColorToRGB example, but it's still not so good.
These examples need a lot of work. C<factorial> might be a better
example than C<fibo>.
=item *
Add more regression tests for normalizers.
=item *
Maybe resolve normalizer function to code-ref at memoize time instead
of at function call time for efficiency? I think there was some
reason not to do this, but I can't remember what it was.
=item *
Add more array value tests to the test suite.
Does it need more now?
=item *
Fix that `Subroutine u redefined ... line 484' message.
Fixed, I think.
=item *
Get rid of any remaining *{$ref}{CODE} or similar magic hashes.
=item *
There should be an option to dump out the memoized values or to
otherwise traverse them.
What for?
Maybe the tied hash interface taskes care of this anyway?
=item *
Include an example that caches DNS lookups.
=item *
Make tie for Storable (Memoize::Storable)
A prototype of Memoize::Storable is finished. Test it and add to the
test suite.
Done.
=item *
Make tie for DBI (Memoize::DBI)
=item *
I think there's a bug. See `###BUG'.
=item *
Storable probably can't be done, because it doesn't allow updating.
Maybe a different interface that supports readonly caches fronted by a
writable in-memory cache? A generic tied hash maybe?
FETCH {
if (it's in the memory hash) {
return it
} elsif (it's in the readonly disk hash) {
return it
} else {
not-there
}
}
STORE {
put it into the in-memory hash
}
Maybe `save' and `restore' methods?
It isn't working right because the destructor doesn't get called at
the right time.
This is fixed. `use strict vars' would have caught it immediately. Duh.
=item *
Don't forget about generic interface to Storable-like packages
=item *
Maybe add in TODISK after all, with TODISK => 'filename' equivalent to
SCALAR_CACHE => [TIE, Memoize::SDBM_File, $filename, O_RDWR|O_CREAT, 0666],
LIST_CACHE => MERGE
=item *
Maybe the default for LIST_CACHE should be MERGE anyway.
=item *
There was probably some other stuff that I forgot.
=back