develooper Front page | perl.perl5.porters | Postings from November 2001

Re: restricted hashes, and other readonlyness (was "clamp...")

Thread Previous | Thread Next
Michael G Schwern
November 3, 2001 19:15
Re: restricted hashes, and other readonlyness (was "clamp...")
Message ID:
On Sat, Nov 03, 2001 at 11:07:02PM +0000, Nick Ing-Simmons wrote:
> It is also missing what to me is the fundamental point.
> A struct-oid is not to be thought of as a hash - if you stop thinking of 
> it that way it stops hurting. The problem with pseudo-hashes was 
> people treated them as hashes ... the problem with fixed-key hashes it 
> people _know_ they are hashes.

Yes, that is the fundamental point.  People want to use them as hashes.
There are two solutions:

    1)  Tell them not to treat them as hashes.
    2)  Make the more hash-like.

We tried #1 with 5.005 pseudo-hashes.  Result?  They were difficult to
use and thus rarely used.  With 5.6 we moved towards #2.  Result?
They were still difficult to use, but for other reasons. ;)

If you had someone something that looks like a hash, they're going to
try to use it as a hash.  Why?  Hashes are useful and flexible.
Structs have narrow utility (in Perl anyway) and are rigid.

We've tried presenting "something that looks like a hash but isn't
really a hash and you shouldn't expect it to work that way" before.
Didn't work.

> >Object persistence with caching.
> Unless I am missing something that is not compelling.
> In order for the object to have its keys "fixed" something 
> has to itterate through the persistant store and enumerate the keys.
> It would seem to me that while we are doing that we may as well cache
> them - and hence they are all present.

It's called lazy caching, we use it a lot.  Consider an SQL table
which represents a set of emails.  It will look something like:

    CREATE TABLE Email (
        MessageID   VARCHAR(80)     PRIMARY KEY,
        Date        DATETIME,
        From        VARCHAR(80),
        To          VARCHAR(80),
        Subject     VARCHAR(120),

        Body        TEXT

The Body is by far the largest part of any email, so to load it when
you don't need it is a huge waste of memory.  On top of that, for most
operations, all you need is the headers.  Thus, lazy caching.  Only
load what you need when you need it.

There are various ways to balance the trade-off between speed and
memory.  Class::DBI does it by grouping together columns that tend to
be used together, so when you load one they're all loaded in one
SELECT.  For the above, you'd probably group all the headers together
and leave the Body seperate.

This simple technique can save heaps and heaps of memory.


Michael G. Schwern   <>
Perl6 Quality Assurance     <>	     Kwalitee Is Job One
We have returned to claim the pyramids.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About