develooper Front page | perl.perl5.porters | Postings from November 2001

Re: restricted hashes, and other readonlyness (was "clamp...")

Thread Previous | Thread Next
Jeffrey Friedl
November 4, 2001 08:39
Re: restricted hashes, and other readonlyness (was "clamp...")
Message ID:

Nick Ing-Simmons <> wrote:
|> >|> I would like concrete examples of places where delete-ing keys is 
|> >|> vital to the application.
|> >

|> >You really can't imagine an object that is intended to be used with a
|> >fixed universe of keys, yet one whose actual membership set within that
|> >universe is dynamic?
|> A. I cannot actually think of one where setting value to undef would 
|>    not suffice.

It would not suffice potentially anywhere where the dual exists/defined
nature of keys is utilized.

Or do you think, perhaps, that in all these years no one has ever really
relied on the difference between exists() and defined(), rather relying
soley on the dual defined/undef nature of values? If you believe that, we
should get rid of exists(). If you think exists() is useful, then you've
thought of a situation where defined() alone would suffice.

|> B. What I can 'imagine' isn't really interesting - I don't want to 
|>    solve imaginary problems, but real ones.

That I can't point you to thousands of instances where this is used in code
you might know is a reflection of my ignorance of the details of code that
I haven't written or studied. Sorry, I'm not omni-anything, except perhaps
omni-annoying? :-)

One (common?) situation that I use it in:

    ## method
    sub GetSomeExpensiveData($)
        my $self = shift;
        if (not exists $self->{CachedData})
            ## Compute the expensive data, and fill $self->{CachedData}
            ## with the result. 'undef' is included among the possible
            ## results, perhaps to say "can't compute", "not applicable",
            ## etc.
        return $self->{CachedData};

An example from my own code is the system that processes news feeds for
Yahoo! Finance. We have one object per news source, each which inherits
from a base "Feed" object. The main work of the individual per-source
objects is to set up a Feed configuration hash that the rest of the system
uses. In that hash, for some keys, it matters if a value exists or not
(where existing while undef is different from not existing). One key, for
example, indicates whom to contact in case of an error. Undef means "don't
contact anyone", while !exists() means to contact the default address.
That type of logic is used in several places.

Of course, I could have ignored Perl's richness and solved the problem in a
different way that didn't involve exists(). But it's Perl and was
programmed as such, but gee, I'd still like the 'use strict' kind of
protection this whole clamp/restricted/pseudoenumerated thing is all about.


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