Re: the status automation machine graph for frysk

[Mark Wielaard <mark at klomp dot org>]

On Tue, 2006-07-04 at 14:43 -0400, Sami Wagiaalla wrote:
> >> - Some methods like handleAddObserver() and handleDeleteObserver()
> >> always do the same thing and never actually do any state transition.
> >>
> >> This adds a lot of (duplicate) code without being clear what it has to
> >> do with with the actual state machine.
> >>   
> > Duplicate code worries me too. Inheritance is a solution but as Cagney 
> > as mentioned
> > before: the flat code is easier to read. Also I would much prefer that 
> > I accedentaly forget
> > to implement a function casing frysk to crash than accidentally pick 
> > up a function from a
> > parent and do incorrect handling.
> 
> One way to get rid of duplicate code is to have static utility functions 
> that do the repeated
> code. I know this doesnt feel very OO... what do u think ?

I think that would actually be fine. That way you can write out all the
state transitions but have the actual implementation pretty small (just
a call to one or two static methods). Assuming we name the methods
nicely it could be pretty readable.

Now that I better understand the TaskState (subclasses) design I think
it might be clearer if we group things a little more in separate files
for each "cluster" of TaskState subclasses (Attached, StartMainTask,
StartClonedTask, Running, BlockedSignal). Then it is easier to see all
state transitions of a group of subclasses together. (*)

Cheers,

Mark

(*) I am sure someone will now jump up and show some way to do that
easily with the eclipse class browser :)