in reply to Re: Comparing all keys in a hash
in thread Comparing all keys in a hash

demerphq, I feel I should put you out of your misery.

This code is part of an application process monitoring GUI, that uses Tk. The hash keys are process IDs, and this sub is used to decide whether anything has changed (hence whether to backtick a ps and poll the application's control files - which are expensive activities).

In practice, the code only needs a zero or non-zero value, so the spaceship operator like return value is overkill. After writing the code, it seemed like an interesting exercise to see if the code could have been written better, hence my meditation on PM.

Hope this answers your questions. Your post has prompted me to add some comments to the code.

Replies are listed 'Best First'.
Re: Re: Re: Comparing all keys in a hash
by demerphq (Chancellor) on Mar 21, 2003 at 14:54 UTC

    Ok. Now I get it. :-) Personally I would return very different results...

    # Determines if two hashes have different keys # If the hashes are different: # In list context returns two array refs, each # containing the missing elements from the other # In scalar context returns an AOA, with a similar # content as above # Otherwise # Returns the empty list or undef as appropriate. # Thus # A true return means they hashes are different, # a false means they have identical keys sub hash_key_diff { my ($x,$y)=@_; my (@x,@y); foreach my $k (keys %$x) { push @y,$k unless exists $y->{$k}; } foreach my $k (keys %$y) { push @x,$k unless exists $x->{$k}; } return @x||@y ? wantarray ? (\@x,\@y) : [\@x,\@y] : () }

    This seems like a much more reasonable return to me, and considering the use you put it to it would seem to be more convenient as well: this would give you a list of processes that have been removed, as well as processes that have started.

    BTW: You didnt overlook my point about the sort order did you?

    Anyway, thanks for the explanation.


    ---
    demerphq