Well off the top of my head...
1. There is no need to do this! That's a big reason.
2. This is an overly complex calling syntax that is
non-standard versus Perl norms. In general coding confusion into the
program is not a good idea. That is an opinion. But I think that tricky
non-standard things should be avoided.
3. This would interfere with some Perl debugging features.
$subname = sub{...blah..} is ref to an anyon sub. Consider:
sub whoami { (caller(1))[3] }; #returns name of the sub that called
+this sub
sub whowasi { (caller(2))[3] }; #returns name of the parent of the su
+b that called this sub
In the case of $subname, there is no "name". I sometimes use code like whowasi() for
debugging to trace back to where some weirdo sub input came from. If you are proposing to
put a large number of anon subs in a module, this kind of idea breaks.
Just because something is possible, doesn't mean that you should do it.
For me: no need, overly complex, non-standard is enough. As I mentioned above there are ways to regulate what sub names get "exported" from a module which is a subset of the names in the package symbol table. There are naming conventions for OO methods like (_xyx is private). All that is "good enough". |