Peter, Peter Scott <pe...@psdt.com> wrote on 04/09/2010 03:45:54 AM: > Yikes, I do not like that design. Forking should be defined in its own > independent location, not as some part of a global funnel that all method > calls pass through.
AFAIK Method attributes are per-package. I am already using Moose to implement the "Command" design pattern. The "Command" role -- along with a dispatcher -- does the whole forking and signal handling, the rest of the software doesn't know about it. It works pretty smoothly right now, and the top would have been some syntactic sugar. > I suspect you would have an easier time if you wrote what sounds like a > largish project using Moose and composed in a forkable role. If you must > use method attributes there is MooseX::MethodAttributes but (and I am > getting beyond my experience here) it does not appear popular. Hm, what else would you have prefered? Right now I use a r/o attribute to set up a per-class list of methods that do not fork (actually, more commands *do* fork than not). Method attributes would have eliminated some typos. *grin* TIA, Eric -- Eric MSP Veith <eric.ve...@de.ibm.com> Hechtsheimer Str. 2 DE-55131 Mainz Germany IBM Deutschland GmbH Vorsitzender des Aufsichtsrats: Erich Clementi Geschäftsführung: Martin Jetter (Vorsitzender), Reinhard Reschke, Christoph Grandpierre, Matthias Hartmann, Michael Diemer, Martina Koederitz Sitz der Gesellschaft: Stuttgart Registergericht: Amtsgericht Stuttgart, HRB 14562 WEEE-Reg.-Nr. DE 99369940 -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/