Front page | perl.perl5.porters |
Postings from July 2001
On Thu, Jul 19, 2001 at 11:15:12AM -0700, Jeffrey Friedl wrote:
> I added a new reserved word (I can hear the cringing already) "clamp".
Here's my thoughts about any new attempt to replace pseudo-hashes,
sort of a minimal requirement set.
1) They should act *just like regular hashes* except in that their keyset
is fixed.
In the early days of pseudo-hashes, this was not so. delete() didn't
work and exists() would return whether or not a key was allowed, not
if that key had been used yet. This ment any subroutine that used
delete() or exists() had to take into account whether or not it was
passed in a pseudo-hash or a regular hash. Nightmare. It was
eventually corrected.
Essentially, the following code should work exactly the same way
whether or not %hash is a normal hash or has a fixed keyset (assuming
'foo' is in that keyset and %hash is initially empty).
exists $hash{foo}; # false
defined $hash{foo}; # false
keys %hash; # empty list
$hash{foo} = undef;
exists $hash{foo}; # true
defined $hash{foo}; # false
keys %hash; # 'foo'
$hash{foo} = 'moo';
exists $hash{foo}; # true
defined $hash{foo}; # true
keys %hash; # 'foo'
delete $hash{foo};
exists $hash{foo}; # false
keys %hash; # empty list
$hash{foo} = 'wibble';
As long as I stick to keys in the hash's keyset, I should not be able
to distinguish between a fixed-key hash and a regular one.
clamp() unfortunately violates this. You have to put all your keys in
the hash before clamping it, so there's effectively no way to
distinguish between a valid key which has not been set yet and a valid
key which is set to undef. I see no way to fix this, given the way
its implemented.
2) It would be nice if you could fix the order of keys() (and thus values())
Everytime I'd go to alter pseudo-hashes and break this, someone would
yell. If we can figure that out it would be nice.
clamp() has no provision for this.
3) They *must not* slow down regular hashes and arrays!
The current pseudo-hash code slows down the rest of Perl. Any
fixed-hash implementation must be careful not to do the same.
Looking at the clamp() implementation, it probably won't interfere.
4) Make sure it works with multiple inheritance.
Pseudo-hashes didn't work at all with MI, this made them very
troublesome for many people. Any fixed key hash system should not
unnecessarily interfere with MI. There may be obvious things, like
two classes using the same key, that will never work. That's ok.
clamp() won't effect this.
5) The interface shouldn't be a mess.
Pseudo-hashes had all sorts of caveats and special cases about their
use. You have to use the typed lexical to get the real efficiency:
my Foo $ph = [];
which everyone forgets. Even worse, there were inconsitencies between
their behavior when typed and untyped.
The idea of clamp() taking all these weird flags makes for a really
ugly interface. Almost nothing in Perl works by combining flag
constants and I can see it all ending in tears. That will have to be
reworked.
6) They should be no more than 15% slower and/or larger than normal hashes.
The big red herring surrounding pseudo-hashes was their extra
efficiency. You actualy only got 15% faster and 15% smaller if used
*very* carefully. Otherwise you were actually 15% slower (but still
15% smaller).
Fulfilling requirements one to five will be hard enough without trying
to make fixed-key hashes *faster* than regular hashes. That was the
great downfall of pseudo-hashes. In trying to make themselves fixed,
fast and compact they complicated their use and broke MI. So I think
we can live with fixed-key hashes that are almost as efficient as
regular hashes. It's still an order of magnitude better than tying.
If you can get them faster *and* fulfill one through five, great!
clamp() looks to be just as fast as regular hashes.
--
Michael G Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
Thread Previous
|
Thread Next