My question about overriding the type-blind behavior of eq (#2) was primarily a question about Perl idiom. Before I settled on a solution, I wanted a better understanding of the Perl syntax for handling various definitions of equality.

I was also looking ahead to future coding scenarios. Part of good design is anticipating the environment around the design. Part of good testing is understanding exactly what one's test for equality is doing. Once I saw my mistake I was worried about what other magic and 'action at a distance' effects I need to consider when writing tests and developing algorithms that involve testing for equality.

So wouldn't it be natural to construct a class "Node", with an overloaded "eq" operator?

The code I'm testing is pretty well factored so the actual fix involves exactly two comparisons within a single subroutine. There isn't really a need for a global solution that will be "carried" with a "node object". Also the "node-i-ness" comes from the fact that the datum is part of larger structure, e.g. an array or a hash. It doesn't need an object wrapper to get that trait.

If there is no ready-made Perl idiom I will probably have my subroutine call the subroutine below for its two comparisons. The subroutine mentioned above needs a definition of equality that duplicates unoverloaded eq, except for the added constraint that like must be compared to like:

sub my_eq {
  # make sure we are comparing like to like
  my $xRef = ref($_[0]);
  return '' unless ($xRef eq ref($_[1]));

  # compare pure scalars and regex's using 'eq'
  # compare reference addresses for the rest
  return ($xRef and ($xRef ne 'Regexp'))
         ? (Scalar::Util::refaddr($_[0])
            == Scalar::Util::refaddr($_[1]))
         : ($_[0] eq $_[1]);
}
[download]

Best, beth