Re: Inheriting variables, super, and "not super"?

On Wed, 10 Dec 2003, Ian Hobson wrote:

> In message <Pine.GSO.4.58.0312091649360.13219@neelix>, Hugh Sasse Staff
> Elec Eng <[e-mail]> writes
> >Is there a way in a method to say
> >"ignore this if called as super"?
> >
> [Big snip]
> >Any ideas?  Apart from "If you're in a hole, stop digging" :-)
> >
> >        Hugh
> >
> >
> Hi Hugh,
>
> I think I have some idea of what you are trying to do, and perhaps some
> understanding of how you got into the wrong hole.
>
> Hint one - in trad programming you think of the data and how it needs to
> be manipulated. For OO Programming you think of the package of
> behaviours you need and create a class to behave in that way. Ignore the
> data - it will fall out of the other thinking.

Yes, though I've not found the last bit comes so easily :-)
>
> So. To your state machine.
>
> I would set up the state machine as a tree (or network if you must),
> where each node type is a different class. Inherit all (tree) nodes from
> a node type that knows how to manage its children.

Yes.  That's my basic design....
>
> You can now walk the tree to change your state. At each node, you call a
> 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!

>
> So in stead, you create a visitor class. This visits the node by sending
>
>     node.acceptVisit(self)  to the node it wants to visit, which simply
> calls
>
>     aVisitor.hasVisitedNodeType(self)
>
> Where NodeType is different for each class of node.  (This is called
> double despatch.)

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)  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"?
(http://www.pragmaticprogrammer.com/developers/ppllc/papers/1998_05.html)
Is that the idea?  I've read about the visitor pattern but it has
not really clicked, with me.

>
> 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,....

> calls can have params to pass the information it needs, or it can pass
> self as shown, and then visitor uses node's accessors.

...and where to send them in the current state?

>
> This gives the visitor method all the info it needs to take its action,
> and decide where to go next.
>
> To use, you create a visitor and let it loose on the root node. It
> crawls over the tree, going its job. The tree neither knows nor cares
> who has visited.
>
> To do another job, create a new visitor class.
>
> Example  - if the tree represented an expression, one visitor could
> report it in infix notation, another generate code to compute it and a
> third evaluate it directly, and a forth....  you get the idea.

So the visitor IS the current state?  I'll have to re-read my [GOF]
in the light of this....
>
> Regards
>
> Ian

        Hugh, pondering...