I only skimmed the RPC article, but I have experience with things like this in CGI. I use an "event dispatching framework" for many of my CGI applications. Basically, an event comes in from the client via qstring or post. This event is translated into a sub call.

The most traditional way of doing this, as the RPC article talks about, is to use a function mapping hash. People don't like to maintain these.

The RPC article suggests iterating over the symbol table. Chances are, that was a lot easier to describe than using attributes.

Using attributes in Perl is a little tricky. To compound that, many people don't understand the basic concepts of sub attributes and, of course, Perl's version is still in "beta" and subject to change.

So, for a public article such as this, using the symbol table approach was probably a good idea.

Now, using attributes is cleaner (IMHO) and can be done just as easily, once you get the nack for Attribute::Handler. Also, it is (again IMHO) more flexible.

Now, back to my CGI event handling framework. I tried using attributes, but found them substantially slower than my current strategy. Currently, when I process the event string, I add "event_" to the begining of it. Then I check to see if that sub exists. If so, I execute it. When I tried attributes, I would hash the names of all the subs marked as event handler. Then, When I get an event string, I would just look in the hash to see if that sub exists. If it does I would have its ref and execute it. But, I found this to be much slower than my current version.

I suspect (and I have no proof of this) that the current implimentation of attributes in Perl isn't as optimal as it could be yet (it is, of course, pretty new). To compound the issue, this was CGI. In a mod_perl environment, the extra initial overhead would not have been a problem.

There are major concerns with using Attributes (particularly ones that use Attribute::Handlers) in combination with mod_perl. This is due to the fact that Attribute::Handlers uses CHECK blocks (by default, anyway) to set up the subroutine attributes and CHECK blocks don't run under mod_perl. Thus, the symbol table approach is not dependent on compilation stages and is sure to be in place at runtime.

This is not a new concept -- for example, Module::Build internally marks actions callable from the command line with the prefix "ACTION_". (E.g., "sub ACTION_test"). Its dispatch function just checks that it can("ACTION_$request") and subclasses can add new actions just by adding methods called "ACTION_whatever".

Of course, you can always use attributes directly by defining your own MODIFY_CODE_ATTRIBUTES and avoid Attribute::Handlers altogether as Maypole does.

antirice    
The first rule of Perl club is - use Perl
The ith rule of Perl club is - follow rule i - 1 for i > 1

Not having read the article, I cannot really comment on this in detail. However, as for attributes being generally "useful", I think one of the most elegant uses of attributes I have seen is Test::Class.