my %ops = (
  '+' => sub { $_[0] + $_[1] },
  '-' => sub { $_[0] - $_[1] },
  '*' => sub { $_[0] * $_[1] },
);
[download]

All the subs would have names in this situation but point conceded.

I'd hoped though that it would be reasonably clear that the reason for knowing the name was that I wanted to use a leading underscore to mark which handler subs should be publicised and which should not. That's the only reason - I was hoping a bit of Laziness (altering my naming convention) could save me coming up with any more elaborate means of maintaining a list of which ops should be advertised. ;-)

[Jon]

sub lookup_subname {
  my($pkg, $sub) = @_;

  no strict 'refs';
  return ( grep { $pkg->can($_) eq $sub }
           keys %{"$pkg\::"} )[0];
}

sub foo;
sub _bar;

my %hash = ( foo => \&foo, bar => \&_foo );

for my $f (keys %hash) {
  my $name = lookup_subname __PACKAGE__, $hash{$f};
  printf "%s is %s\n",
         $f, ( $name =~ /^_/ ? 'private' : 'public' );
}
__output__

bar is private
foo is public
[download]

This is the type of thing I had in mind, though you're right broquaint, it's a touch more... verbose than I'd been hoping for.

I guess this is Larry's waterbed theory at work - keeping the dispatch table structure simple just increases the work I have to do to determine some extra info from the sub names.

Thanks,

[Jon]

use constant PUBLIC => 0, PRIVATE => 1;
%query = (
           action1 => { visibility => PUBLIC,
                        code       => \&handler1, },
           action2 => { visibility => PUBLIC,
                        code       => \&handler2, },
           action3 => { visibility => PRIVATE,
                        code       => \&_do_not_advertise, },
          );

my @public_actions =
  grep $query{$_}->{visibility} == PUBLIC, keys %query;
[download]

If that's too verbose, just make subs which do the same thing (e.g. register_private( action3 => \&_do_not_advertise )). Or encapsulate things in a class and make visibility a method.

Update: Or just have a register sub which takes an action name and a sub name and then adds the right elements.

sub register_action {
  my( $action, $subname ) = @_;
  no strict 'refs';
  $query{ $action } = { visibility => ($subname =~ /^_/),
                        code => \&{$subname} };
}
[download]

sub getsubname {
    use B 'svref_2object';
    my $coderef = shift;
    join '::', eval { svref_2object($coderef)->GV->STASH->NAME },
               eval { svref_2object($coderef)->GV->NAME }
}
[download]

Far better, IMHO, would it be to put this attribute into the dispatch-table like so:

%query=('action1'=>[\&handler1,'public'],
       'action2'=>[\&handler2, 'public'],
       'action3'=>[\&_do_not_advertise_this_function_externally,'priva
+te'],
       # and so on
);
[download]

Now you will have to dereference one level deeper to get the sub-reference and the attribute, but that seems a small loss given that you now have the attribute handy in the dispatch-table.

If ever you want to change the public/private atribute, all you have to do is change this atribute in the dispatch-table. In your system, you would have to change the dispatch table and the actual subroutine name itself (and if you ever call such a subroutine directly from somewhere else in your code, you will have broken your program, unless you change the subroutine-call as well -- messy, messy).

With the "attribute" solution you can even change the public/private programatically if necessary. [Whole new vistas of enormous possibilities unfold before your inner eye]

Because then they would not be able to be called at all through the general dispatch. The problem isn't in hiding them from the dispatch; it's in hiding certain ones from a menu or help system so that the user is not presented with options that make no sense in a given context.

But as has already been noted by others, perhaps the best solution is to make the data structure for the dispatch table a little more complex/sophisticated so it can contain the public/private attribute.

[Jon]