On Tue, 2002-04-16 at 14:57, Piers Cawley wrote:
> Aaron Sherman <[EMAIL PROTECTED]> writes:

> > I suspect it would involve:
> >
> > 1. Copying the key (which might be a reference) on insertion.
> > 2. Hashing once, and caching the hash.
> >
> > This means a minimum of overhead, so it's a good thing. It also means
> > that the structure of your hash would never need to re-compute if the
> > hash of a particular object changes (which I would imagine it could
> > easily do in any number of cases).
> 
> So you'd have:
> 
>    %hash{$some_obj} = $aValue;
>    $some_obj.mutator;
>    exists %hash{$some_obj} # returns undef. 
> 
> Somehow I *really* don't think that's going to fly.
> 
> Personally I'd like the default hash to return some immutable, unique
> and probably opaque object id (something the like
> 'Foo=HASH(0x81e2a3c)' you get from unoverloaded objects in Perl5, but
> probably not identical). This isn't going to change as an object's
> contents change.

I don't see why your above example would behave as you suggest. Larry
has already put in his TMTOWTDI comment, but let's look back at what I
said, using your example:

    %hash{$some_obj} = $aValue;

1. Copy the key (possibly a reference)

    %hash.magic_key_store($some_obj)

2. Cache the hash of that key

    %hash.magic_hash_store($some_obj.hash())

Now, you suggest:

    $some_obj.mutator;
    exists %hash{$some_obj} # returns undef. 

Well, if you want that behavior, I'm sure you can get it by redefining
hash() (or whatever the operator/method/whatever is called), but I don't
suggest it in the normal case. By default, as I've suggested in previous
mail the string representation should be used for hashing, which would
lead to that second statement returning true, since $some_obj still has
the same string representation.

Then again, if you're hashing by (as in my previous example) file name,
then you might want to change the hash of your object when it represents
a different file (say, you call an open method on it). There's good
cause to want to do that.

What I was saying above, however, was that you don't want to have to
re-compute your internal hash structure on the fly, hence caching the
hash of your object. That way, if an object returns a 1k block from
/dev/random as it's hash, you don't re-build the entire hash every time
you access an element, which would be absurdly unfortunate. Is there
ever a reason to want to do that?


Reply via email to