RE (tilly) 1: On elegant coding...

First of all I agree with the various thoughts and points you make. So let me just comment on the example.

I see what you mean. Aesthetically I don't like the exit condition being woven through the logic, what happens if some day you want to have this cache updating be part of a longer-running script? Also reading the logic through I saw a lot of combinations of actions being taken, but it was not at all obvious why some of them were. And the nesting is pretty darned deep.

I used an indicator variable to do the actions and restructured. Comments?

{
  ## main loop
  my $cache = 'current';  # Hope for the best
  if (not cache_is_good()) {
    $cache = 'stale';  # Changed expectations
    if (i_am_the_writer()) {
      if (cache_is_stale()) {
        unless (start_background_update()) {
          $cache = 'current'; # Gotta do it foreground
        }
      }
      else {
        $cache = 'current'; # Have nothing to show, gotta do it
      }
    }
    elsif(not cache_is_stale()) {
      # Stuck, gotta retry
      close_cache();
      sleep 5;
      redo;
    }

    update_cache() if $cache eq 'current'; # Make it so
  }
  show_cache($cache);
}

sub start_background_update {
  # NOTE: Uses implicit returns.
  if (i_can_fork()) {
    unless (i_am_the_parent()) {
      be_a_child();
      update_cache();
      exit 0;
    }
  }
}
[download]

UPDATE
Yeah, I know. I was using implicit returns without a comment. At the time it made sense, but that is the kind of thing I rethink and mention shortly after...

Comment on RE (tilly) 1: On elegant coding... Download Code

Replies are listed 'Best First'.
RE: RE (tilly) 1: On elegant coding... by merlyn (Sage) on Oct 14, 2000 at 08:03 UTC
I'm not a real big fan of state variables, and in fact, for this example, I had tossed around doing some status checks similar to what you've done, but rejected it after a couple of false starts. The problem with state variables is that they introduce some additional coupling: What if the variable gets set to a value other than the legal values (or not initialized)? You could branch more often or less often than you think. What if you refactor and now need a finer-grain distinction (stale vs real stale)? How do you track down which values to check, or does it now need some disjunctive tests? Tracing the program flow now also requires a data simulation as well. Yeah, again, just reporting on where I've been burned. But I think I've got enough scars to not just be a guy in a diner on this one. You know, the guy at the end of the counter who has an opinion on everything even though he's not been there? {grin} -- Randal L. Schwartz, Perl hacker	[reply]
RE (tilly) 3: On elegant coding... by tilly (Archbishop) on Oct 16, 2000 at 17:00 UTC
I am not the greatest fan of state variables either. But the state variable always was initialized, information on what values were legal appeared fewer times within fewer lines of code than the original, and I was only resorting to it to remove something else that I disliked even more. And I note that it is an idea that you tossed around as well. :-) To tell the truth, were this my problem with my stuff I would look at the logic and reconsider whether I need to be fancy and fork. Since my stuff likes to run in crons and long-running jobs, I would be able to say "no" and get drastic simplifications. Down to "until it is safe to read, become writer and be sure it is fixed, once safe to read then read". But there is an obvious solution that doesn't involve state, and that is to make your loop into a real function, and then return out of the function rather than call a function that exits. Combine with runrig's organizational skills... :-) As for the diner, yeah, that hits home. And you know it. So let me explain. It has to do with my learning style. I found out many years and subjects ago that I learn best by going out and finding out everything that I can, trying to integrate that into a solid understanding, and then articulating my understanding in the presence of people who know better than I do. If they correct, then analyze the corrections, integrate that into my understanding. Wash, rinse, and repeat until satisfied. Which boils down to one thing. I am a lot like that guy at the end of the counter except in one huge detail. I learn! Besides which, I have been more places than you might think...	[reply]