Front page | perl.perl5.porters |
Postings from January 2017
On Sat, Jan 28, 2017 at 3:31 PM, demerphq <demerphq@gmail.com> wrote: > 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 As far as I know they're only used in the fields implementation, and were introduced when pseudohashes were abolished. I believe readonly hashes are generally far more useful, and that fields can be implemented quite easily on top of a pluggable hash API. LeonThread Previous | Thread Next