develooper Front page | perl.perl5.porters | Postings from January 2017

Should we consider locked hashes a failed experiment?

Thread Next
January 28, 2017 14:31
Should we consider locked hashes a failed experiment?
Message ID:
My experience with locked hashes is that as currently implemented they
are nearly useless. A simple read of a non-existent key becomes a
fatal exception, which makes them nearly unusable in conventional
code. At work we have tried to use them for a few purposes, and
generally it is has been a failure.  They impose a run time penalty on
all hash access even though they are barely used.

As far as I can tell locked hashes were invented as a way to work
around our lack of core support for true objects/structs. (Where
accessing a non-existent member *should* throw an exception, but
preferably a compile time one.) However with perls standard object
model and usage patterns I have never really seen anyone use them this

Steffen has started working on a patch series to make hashes
pluggable. (Big big fricking A to him on that!) This is only going to
be more complex if we support locking (does every hash implementation
have to support locking? Does the hash api have to support

I propose that we get rid of locked hashes. I have written tons of
code to help support them, and I consider them a total failed

Also, use of clear_placeholders and related functionality is one of
the "hidden apis" which we have in Internals that really has no
business being exposed to end users.

Once we have a pluggable API for hashes, we can implement lockable
hashes using them and if people really want them we can provide them.

What do people think? Should every hash access and store pay a penalty
for locked hashes when they are almost unused?


perl -Mre=debug -e "/just|another|perl|hacker/"

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