| Name : perl-Tie-Hash-ReadonlyStack
| |
| Version : 0.2
| Vendor : obs://build_opensuse_org/devel:languages:perl
|
| Release : lp155.7.1
| Date : 2023-07-20 19:15:53
|
| Group : Development/Libraries/Perl
| Source RPM : perl-Tie-Hash-ReadonlyStack-0.2-lp155.7.1.src.rpm
|
| Size : 0.02 MB
| |
| Packager : https://www_suse_com/
| |
| Summary : Treat multiple hashes as a single hash and do not modify original hashes[cut]
|
Description :
The tie via this module has 2 main behaviors.
First, it treats a stack of hashes as a single unit similar to the
Tie::Proxy::Hash manpage (but without the \"translation\" mechanism and some
other differences)
This allows you to have your main hash and then assign hashes to look for
the given key in either before or after the main hash.
See the the /SYNOPSIS manpage for an example of that.
Second, it allows you to use hashes that are readonly in said stack without
fatal errors.
For example, say you you have a hash created via, ironically enough, the
Readonly manpage. If you try to assign to it:
Readonly::Hash my %readonly => ( ... );
$readonly{\'key\'} = \'value\'; # throws \"Modification of a read-only value attempted at ...\"
or say you have a the GDBM_File manpage file tied in readonly mode:
tie my %gdbm, \'GDBM_File\', \'data.gdbm\', &GDBM_READER, 0640;
$gdbm{\'key\'} = \'value\'; # throws \"gdbm store returned -1, errno 0, key \"key\" at ...\"
print $gdbm{\'key\'}; # never gets here
print $gdbm{\'abc\'};
You could wrap such assignments in an eval but not only is that cluttered
the value is unchanged (sort of what \"readonly\" means ;p)
Putting that hash into a Tie::Hash::ReadonlyStack hash allows you to assign
new values without modifying the hash it came from.
tie my %gdbm, \'GDBM_File\', \'data.gdbm\', &GDBM_READER, 0640;
tie my %data, \'Tie::Hash::ReadonlyStack\', \\%gdbm;
$data{\'key\'} = \'value\';
print $data{\'key\'}; # prints \'value\'
print $data{\'abc\'}; # prints the value of \'abc\' from the database
Besides the fact that storing a new value won\'t trigger fatal errors on
various sorts of readonly type hashes it also has another benefit:
Sometimes a hash keys\'s value is used to calculate a new value and the new
value is re-stored as a cacheing mechanism.
For example, with a the Locale::Maketext manpage Lexicon hash: a key is
looked up, compiled into an internal form, and re-stored as a reference,
typically a SCALAR or CODE. the Template::ToolKit manpage can do similar
behavior. If your tied hash stored the new value in your database then the
next time it is used, you\'d probably get something like \'SCALAR(0x800ab0)\'
or \'CODE(0x800ab0)\' instead of the string you expected.
In short, keeping all new values internally as part of the
\'Tie::Hash::ReadonlyStack\' is a good thing because it:
* * keeps the orignal hashes unmodified (i.e. does not stomp on things you
might not want stomped on)
* * will make readonly hashes not fatal when values are changed
* * allow values to be changed for local pruposes (i.e. as part of a
calculate-then-cache mechanism)
|
RPM found in directory: /packages/linux-pbone/ftp5.gwdg.de/pub/opensuse/repositories/devel:/languages:/perl:/CPAN-T/15.5/noarch |
