On Thu, 11 Dec 2003, Ian Hobson wrote:

> Hi Hugh,
>
> In message <Pine.GSO.4.58.0312091953180.856 / neelix>, Hugh Sasse Staff
> Elec Eng <hgs / dmu.ac.uk> writes
> >On Wed, 10 Dec 2003, Ian Hobson wrote:
> >
> >> method to handle what needs doing at that state. The problem with this
> >> is that the code to handle all the types of state are scattered across
> >> lots of classes. Yuck!
> >
> >Yes, but the code to handle each state is as local to that state as
> >possible, avoiding repetition of things in the ancestors.  The
> >complexity *is* difficult (for me) to manage.  It sounds like you are
> >saying this is not really a sad reflection of my ability to program,
> >which is encouraging!
> >
> I didn't think it for a moment. State machines are hard!

No, just how I felt about the experience.  Yes, they seem to be
difficult, even though they simplify things!
>
> >>
> >I've encountered the term double dispatch in the context of nested
> >case statements, I think.  I can't see how these are two
> >representations of the same thing...  (That probably doesn't matter
> >here, anyway)
> They are the same thing - the nested case statement is how it appears in
> procedural form.

After reading my [GOF] and the web somewhat I see how these relate
now.

> > The need for both calls is that the visitor may need
> >to tell the Node to give it some kinds of information, and to have
> >the Node call a method on the visitor means they both do "Tell,
> >Don't Ask"?
        [...]
> >
> Yes, but weakly. If the visitor simply told the node it has been
> visited, then the node would contain all the behaviour needed to act on
> that event.
>
> By moving all this code from the nodes to the visitor class, it becomes
> much easier to write. But it does go a bit against tell, don't ask.
>

It is possibly like the visitor Telling the node Tell me what you
want, rather than asking it "is this what you want"
> >>
> >> Then your visitor class has *all* the matching  hasVisitedSomwhere
> >> methods, to handle all the actions you need. The hasVisitedSomewhere
> >
> >So it "knows" about all the events the system can respond to,....
> Yep - all in one source file.

This was conterintuitive, normally you don't couple things that
tightly.  I think I understand it better now.  My problem now is
that I'm beginning to think I need triple dispatch. the state
classes, the visitor (the application), and the GUI, with the GUI
either as a collection of states or as another visitor to the state
heirarchy.

> >..and where to send them in the current state?
> I think so in this case.  Where to go next can be decided by the
> visitor, the node or an external walker. To my mind, the flexibility
> offered by having the visitor class decide is well worth it.
> >
> >So the visitor IS the current state?  I'll have to re-read my [GOF]
> >in the light of this....
> Yes - the visitor and its internal state, are the current state.

I think this pattern will be really useful elsewhere in this
application as well, where all properties of each user must be
processed in various ways.
>
> Regards
>
> Ian
>
        Thank you,
        Hugh