Front page | perl.perl5.porters |
Postings from July 2001
Nick Ing-Simmons wrote: > Jeffrey Friedl <jfriedl@yahoo.com> writes: > >>Nick Ing-Simmons <nick@ing-simmons.net> wrote: >>|> readonly \%hash; # clamped >> >>I reiterate that I believe that this would be a mistake. >> > > to which I reiterate that that was pseudo code example of the > implementation - not an interface definition. > I was trying to demonstrate that with "hooks" e.g. by readonl() xsub, > and minor tweaks to the core adding some "dies" we can implement both. > > I leave it up to list as a whole to discuss what it should look like > to user. Language-level idea: readonly keys %hash; readonly values %hash; readonly %hash; The idea is that you set components of the hash to read-only -- the hash keys, or values associated with keys, or everything. readonly keys %hash -- most obvious meaning is that you cannot add or delete from the currently existing keys (the set of keys is immutable). If that really is a bad idea, it could just mean that the set of *valid* keys is immutable, but you can delete a key and re-add it but not add a key that did not exist at the time of setting the hash keys readonly. readonly values %hash -- which value is assigned to a key cannot change. readonly %hash -- both of the above None of the above make the values themselves readonly. That would still be readonly($_) foreach values %hash Reading an invalid key from a hash whose keys are readonly could then trigger a warning "value fetched from hash guaranteed to be undefined, stupid". Compile-time when possible (constant), run-time otherwise. Just a thought. Unfortunately not implementable as an xsub. To make it xsubbable, make the keys %hash list remember where it came from, or allow xsubs to set user-defined context description bits. Both of those sound pretty hairy, though the second one is crazy enough to be interesting. (And preserves the semantics better.)Thread Previous | Thread Next