On Dec 15, 2004, at 7:04 AM, Tim Bunce wrote:
There's a Computer::Theory::FSA module already:
http://search.cpan.org/~frighetti/Computer-Theory-FSA-0.1_05/lib/ Computer/Theory/FSA.pm
but it doesn't look pleasant to use.
That was the problem with DFA::Simple, as well. Not simple.
FSA::Rules seems okay, but it doesn't express the simple utility of the module. I hate to suggest FSA::Simple but it almost seems appropriate here.
By "simple utility", do you mean "simple to use" or "it doesn't do much"? I'm hesitant to use FSA::Simple, because I think that "Simple" and "Lite" are seldom either (see SOAP::Lite and Pod::Simple).
Having said that it looks like an interesting module. Id be curious as to
what you use it for tho.
I'm looking for a simple FSA module to help manage states in a GUI.
Cool! Since I've been using DBI for 6 years, it's only fair that I finally write a module that you can use. :-)
Some quick observations:
- I'd prefix some of the actions with "on_"
on_enter => sub { ...},
on_leave => sub { ...},
because they don't 'perform' the enter/leave they're just triggered by it.
Agreed. I'd actually done just that in my App::Info module some time ago, so I should've thought of it before.
- The docs aren't very clear about when "do" actions are run. They talk about "while in the state" and "in the state". Saying "after entering the state" would be more clear.
Thanks, I'll expand on that. Clarity of docs are always my biggest problem--I tend to assume too much foreknowledge.
- Using undef to mean 'always' in the goto rules is confusing. Using 1 (or any true scalar) would seem more natural.
Oops. I had that because I was borrowing from DFA::Simple, but then I realized that it was a stupidly unidiomatic Perl, so I changed it to just return whatever scalar value is passed. So undef is false, now. I just forgot to change the docs.
I could add a global setting of some kind to add a print statement at the beginning of each action (on_enter, on_leave, goto rules). Just set it and it prints stuff to STDERR. Even better would be a global callback code reference so that a user could specify an action for every state and transition. That would be cool. Something like this:- Hooks for tracing execution would be helpful. Using empty methods and requiring users to sub-class would suffice.
DFA::Rules->trace(1);
DFA::Rules->trace(sub { print shift->state });Hrm...it would be helpful then to have a state of the state (am I entering, leaving, in the state, transitioning?). I'll have to think about that.
This is the downside to getting such great feedback on a module--I then burn more time adding cool features that people suggest. :-) Look for something like this in a future version (not the first CPAN release).
- There's scope for refactoring into finer-grained methods.
Such as? I'm not sure what you mean here.
- I'd suggest renaming check() to attempt_transition() and have it return
the new state or undef (not croak) if it can't transition at the moment.
How 'bout I borrow DFA::Simple's "Check_For_NextState()"? No? "attempt_transition()" is a bit long. Maybe "eval_rules()"? Right now check() returns the object itself and croaks on failure.
- Then define check() to be { self->attempt_transition() || croak ... }
But a better name than check() would also be good.
Ah, I guess you like the idea of attempt_transition() returning undef on failure but not die'ing, eh? I guess it'd be easy enough to support both approaches, as you suggest.
- Looks good!
Thanks!
Any idea how soon it might reach CPAN once a name is chosen?
Today is my plan.
Regards,
David
