Re: Extending gcjx visitor pattern

[Mike Emmel <mike dot emmel at gmail dot com>]

On 12/6/05, Cédric Berger <cedric@berger.to> wrote:
> Ranjit Mathew wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Mike Emmel wrote:
> >> I was wondering what people would think about extending the gcjx
> >> visitor to also forward
> >> user data.
> >>
> >> I.e visit_method (model_method * method,
> >>                 const list<ref_variable_decl> & params,
> >>                 const ref_block &block)
> >>
> >> would becomes
> >>
> >> visit_method (model_method * method,
> >>                 const list<ref_variable_decl> & params,
> >>                 const ref_block &block, void * visitorData );
> >
> > If I understand you correctly, you want the Visitor to
> > say:
> >
> >   someObject->visit (this, opaqueBlob);
> >
> > and then the visited object (Visitee?) to call back
> > the appropriate visit_snafu() method like:
> >
> >   visitorObject->visit_snafu (this, foo, bar, opaqueBlob);
> >
> > Right?
> That's certainly the way most people implement these kind of things
> int the C language, so you don't need to put your context data
> (opaqueBlob) on global or thread-local memory, which is very unclean
> and error-prone.
>
> But in the OO case, you can just attach the context data inside the
> visitorObject, which, if I understand correctly, is forwarded across
> all the call tree. Anonymous subclasses of visitorObject might be
> handy.
>
> Cedric
>
>
Thats the way I'm doing it now. It works okay I'm not certian its
better then passing the current state on the stack  just different.
The only issue here is if I get into a situation where I need to start
pushing state onto a stack so far thats not come up. Then I need at
least and object to save the current visitors state in.  If I
understand you right about the anonymous subclasses I think the idea
is you start with one visitor instance and actually change the visitor
as you descend the tree replacing the current one with specialized
subclasses ?
I'd assume they would be chained returning visiting to there parent
when its done.

Cool idea better then simply pushing state on a stack.

Mike