Front page | perl.perl5.porters |
Postings from January 2017
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 way. 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 "clear_placeholders"? 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 experiment. 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? Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Next