Bug #37835 for POE: POE::NFA api

Mon Jul 21 22:11:26 2008 WHOPPIX [...] cpan.org - Ticket created

Subject:

POE::NFA api

I would suggest two additions to the POE::NFA api. First, i think it would be good to have a normal HEAP for each NFA session, not just the runstate. It occurred to me, that there often is some data that has to be available in every state. (For example a ReadWrite wheel, which can be shutdown from whichever state, and so on) Further, i would suggest adding three new parameters to the ->spawn() method: heap => {} # put something in the heap runstates => { initial => {}, # data that is available in $_[RUNSTATE] in the # initial state. } I think those two things are very important to make POE::NFA useable, if you can't initially put something into the NFAs heap, you need to use dirty workarounds (posting the data, putting it into a glob, or whatever)

Fri Sep 12 18:46:03 2008 WHOPPIX [...] cpan.org - Correspondence added

also, i suggest that it could be usefull to have a state "all", and all event handlers installed under "all" are available from all states. This would make it much easier to install state-independent event handlers, which are, otherwise tedious, because you have to add them to every state.

Sat Sep 13 06:36:37 2008 WHOPPIX [...] cpan.org - Correspondence added

another thing i noticed, is that POE::NFA doesn't have the _default handler. However, i think the default handler is very important for a POE::NFA session, because it can be used to inform the user if he sent a signal that is not available in the current state.

Wed Jan 21 06:00:17 2009 hinrik.sig [...] gmail.com - Correspondence added

Another oft-requested feature is object_states (and package_states too, I suppose) as implemented by POE::Session.

Sun Feb 22 02:43:18 2009 RCAPUTO [...] cpan.org - Correspondence added

On Mon Jul 21 22:11:26 2008, WHOPPIX wrote: Show quoted text

> I would suggest two additions to the POE::NFA api. > First, i think it would be good to have a normal HEAP for each NFA > session, not just the runstate. It occurred to me, that there often is > some data that has to be available in every state. (For example a > ReadWrite wheel, which can be shutdown from whichever state, and so on) > Further, i would suggest adding three new parameters to the ->spawn() > method: > > heap => {} # put something in the heap > > runstates => { > initial => {}, # data that is available in $_[RUNSTATE] in the > # initial state. > } > > I think those two things are very important to make POE::NFA useable, if > you can't initially put something into the NFAs heap, you need to use > dirty workarounds (posting the data, putting it into a glob, or whatever)

I think you misunderstand. POE::NFA's $_[RUNSTATE] is shared among every handler of every POE::NFA state. It is the equivalent of POE::Session's $_[HEAP]. POE::NFA has no per-state storage.

Sun Feb 22 02:50:24 2009 RCAPUTO [...] cpan.org - Correspondence added

On Sat Sep 13 06:36:37 2008, WHOPPIX wrote: Show quoted text

> another thing i noticed, is that POE::NFA doesn't have the _default > handler. However, i think the default handler is very important for a > POE::NFA session, because it can be used to inform the user if he sent > a signal that is not available in the current state.

POE::NFA handles _default, but it's experimental and not documented. Please let me know how you're using it, and whether it's actually useful. Thank you! Please open a separate ticket to track POE::NFA's _default documentation. Thank you!

Sun Feb 22 02:52:40 2009 RCAPUTO [...] cpan.org - Correspondence added

On Wed Jan 21 06:00:17 2009, HINRIK wrote: Show quoted text

> Another oft-requested feature is object_states (and package_states too, > I suppose) as implemented by POE::Session.

Added. Thanks for the suggestion!

Sun Feb 22 02:56:29 2009 RCAPUTO [...] cpan.org - Correspondence added

On Fri Sep 12 18:46:03 2008, WHOPPIX wrote: Show quoted text

> also, i suggest that it could be usefull to have a state "all", and all > event handlers installed under "all" are available from all states. > This would make it much easier to install state-independent event > handlers, which are, otherwise tedious, because you have to add them to > every state.

I work around this by defining a hash of all/global handlers, then including that hash in each appropriate state. This is much more flexible, as I can define hashes for different subsets of functionality, then mix and match them in each state. my %can_handle_commands = ( ... ); POE::NFA->spawn( inline_states => { login => { on_input => \&handle_input, ... }, command => { %can_handle_commands }, ..., }, );

Sun Feb 22 02:59:00 2009 RCAPUTO [...] cpan.org - Correspondence added

The original issue for this ticket was resolved or worked around. Please open tickets for side issues, so that they may be tracked better and you may be notified when their statuses change. A big ticket with a lot of side issues is almost guaranteed not to get done or at least not in as timely a fashion, since all the issues must be addressed before the whole thing can be closed.

Sun Feb 22 02:59:00 2009 RCAPUTO [...] cpan.org - Status changed from 'open' to 'resolved'