Peter,
Peter Scott <[email protected]> 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 <[email protected]>
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: [email protected]
For additional commands, e-mail: [email protected]
http://learn.perl.org/
