in reply to Re: Re: Rethinking Your Program's If-Thens
in thread Rethinking Your Program's If-Thens

As far as the array is concerned, since I don't know the meaning of its fields I had to work with what princepawn gave us.

Thanks for pointing out the module vs main program issue which I omitted even though I was aware of it. I'd prefer the BEGIN in that case: no checks at runtime (CPU efficiency), no extra code to read and write (programmer efficiency).

You are right about &{$ref}() and I usually prefer $ref->() as well. In this case it was a conscious choice because I felt it read better this way considering I embedded the croak in the lookup.

I generally dislike exists tests because they usually force me to spell out the same hash lookup twice. At least in this case we can get away with a simple or-test, because a hash value will either not exist or be a coderef, which by definition is true. Now the choice is to either embed the error check in the call like I did (ugly), or use a temporary variable like so - also ugly:

my $lookup_div_serv = $map{$dcr_type} or croak "..."; return $lookup_div_serv->();
I'd be happy with this if I needed the $lookup_div_serv in muliple places, but I don't. This is basically a case of deciding which ugliness to consider the lesser of evils.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re^3: Rethinking Your Program's If-Thens
by Anonymous Monk on Oct 12, 2002 at 19:06 UTC
    One point. The BEGIN solution isn't best if your block refers to other functions that might be defined later in your code. Being lazy avoids this issue and generally will Do The Right Thing with less attention on your part. Admittedly with a small run-time penalty.