$$_ = node() for \my ($in_neg, $in_pos, $out_neg, $out_pos);

Or more simply, since  $_ is already aliased to each item of the list:

c:\@Work\Perl\monks>perl -wMstrict -MData::Dump -le
"use 5.010;
 ;;
 sub node { state $x = 42;  return ++$x; }
 ;;
 $_ = node() for my ($in_neg, $in_pos, $out_neg, $out_pos);
 dd $in_neg, $in_pos, $out_neg, $out_pos;
"
(43 .. 46)
[download]

Update 1: BTW: Both approaches work under Perl version 5.8.9 (without the use of state of course!).

Update 2: Although I have to say that the first | quoted form could be very useful when iterating over a list of references to arbitrary my variables (actually, I think this would work with any kind of variable, but I haven't tested this):

c:\@Work\Perl\monks>perl -wMstrict -le
"use Data::Dump qw(dd);
 ;;
 print 'perl version: ', $];
 ;;
 init($_) for \my ($scalar, @ra, %ha);
 dd $scalar, \@ra, \%ha;
 ;;
 sub init {
   my ($r) = @_;
   ;;
   return
     'ARRAY'  eq ref $r ? @$r = (9, 8, 7)                 :
     'HASH'   eq ref $r ? %$r = qw(one 1  two 2  three 3) :
     'SCALAR' eq ref $r ? $$r = 42                        :
     die qq{unknown ref type: '$r'}
     ;
   }
"
perl version: 5.008009
(42, [9, 8, 7], { one => 1, three => 3, two => 2 })
[download]

Athanasius:

Thanks for taking the time to take a look at it.

Regarding encapsulation violations: One of them was accidental. After I got the code largely to where I wanted it, I didn't like the delete $g->{nodes}{out_neg} statements, so I created _keep_only_names() to handle that. I put it into the first example, but forgot to put it into the second example. After thinking about it, I think that a better approach would be to tell the simplify() function which names it needs to care about, so I can use the same graph for multiple runs. If I ever get serious about putting more electronics components in there and other network types, I'll probably do something like that.

For the second one, as you mention, I should put the factory functions build_impedance() and build_pad() into the Gr package.

I don't generally write OO code in perl (aside from using packages from CPAN), as generally I use perl for my "let's learn about some problem domain before getting serious" language. I find good OO code really requires you to have a sufficient understanding of the problem domain before you start figuring out what the classes are or should be. I don't often get to use perl at the $job, so I generally use perl to explore the problem, then switch to an "approved" language, with classes and objects and whatnots ;^).

Your solution to removing the duplicate node() calls is amusing looking. I may have to play with it a little and see how I like it.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

If you're making graphs, I'd encourage you to use the Graph module (disclosure: I'm the maintainer). All the bookkeeping is done for you, you can add "attributes" to vertices or edges, and you can stringify them for instant debugging gratification.