Visitor Work

[Michael Rimov]

Hi guys,

I'm getting to the point where I really need to be able to bust out of a visitor
traversal once I've successfully traversed one container.  Normally I would do
that by returning a Boolean flag from the visit*() functions to indicate if I
should continue traversal.

But unfortunately, that would be an incompatible API change.  

Any ideas how to fix this in a compatible way?

                                                                -Mike



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

In change 4330 I added a method to PicoVisitor (corresponding to a JIRA issue)

Make your change and show us the patch ..

- Paul

On Jun 20, 2008, at 3:22 PM, Michael Rimov wrote:

Hi guys,

I'm getting to the point where I really need to be able to bust out of a visitor
traversal once I've successfully traversed one container.  Normally I would do
that by returning a Boolean flag from the visit*() functions to indicate if I
should continue traversal.

But unfortunately, that would be an incompatible API change.  

Any ideas how to fix this in a compatible way?

-Mike



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Michael Rimov]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Ok, here you go.  I ultimately only modified one signature:   boolean visitContainer(Pico).

 

What this allows me to do is pseudo lifecycles that are implemented via Visitors, and most importantly, when I have a stack of 5-6 containers deep, I can make sure I only apply the visitor to one container. 

 

It isn’t the most efficient implementation, but it does cover what I need, and is much less invasive than allowing “abort points” for every visitor callback.  (Which would result in modification of the accept() methods as well)

 

Let me know if this works.

 

                                                                                                                                                -Mike

 

From: Paul Hammant [mailto:paul@...]
Sent: Friday, June 20, 2008 3:40 PM
To: dev@...
Subject: Re: [picocontainer-dev] Visitor Work

 

In change 4330 I added a method to PicoVisitor (corresponding to a JIRA issue)

 

Make your change and show us the patch ..

 

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

Mike,

So its funny Aslak reworked the lifecycle stuff to use a visitor some years ago. I ended up removing it and going back to essentially the current design because visitation thru a tree was going to go to every node regardless of lifecycle strategy choices for each node.  I.e. if you wanted to block traversal at some scope, you could not.  Seems to me that a container should be able to block a number of things its parent is trying to do to it.

So if you were interested there is in Svn (deleted) a LifecycleVisitor.

- Paul

On Jun 20, 2008, at 9:48 PM, Michael Rimov wrote:

Ok, here you go.  I ultimately only modified one signature:   boolean visitContainer(Pico).

 

What this allows me to do is pseudo lifecycles that are implemented via Visitors, and most importantly, when I have a stack of 5-6 containers deep, I can make sure I only apply the visitor to one container. 

 

It isn’t the most efficient implementation, but it does cover what I need, and is much less invasive than allowing “abort points” for every visitor callback.  (Which would result in modification of the accept() methods as well)

 

Let me know if this works.

 

                                                                                                                                                -Mike

 

From: Paul Hammant [paul@...] 
Sent: Friday, June 20, 2008 3:40 PM
To: dev@...
Subject: Re: [picocontainer-dev] Visitor Work

 

In change 4330 I added a method to PicoVisitor (corresponding to a JIRA issue)

 

Make your change and show us the patch ..

 

<visitorpatch.diff>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[Michael Rimov]

>So its funny Aslak reworked the lifecycle stuff to use a visitor some years
ago. I >ended up removing it and going back to essentially the current design
because >visitation thru a tree was going to go to every node regardless of
lifecycle strategy >choices for each node.  I.e. if you wanted to block
traversal at some scope, you >could not.  Seems to me that a container should be
able to block a number of things >its parent is trying to do to it.

Yeah, I remember that stuff.  

If I have the time when Pico 3 rolls around, I'll see about expanding from
there.  

                                                -Mike

P.S. For any lurkers out there, no we aren't even really THINKING about Pico 3
yet! :)



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

I am ;-)

On Jun 21, 2008, at 10:45 AM, Michael Rimov wrote:

>
>> So its funny Aslak reworked the lifecycle stuff to use a visitor  
>> some years
> ago. I >ended up removing it and going back to essentially the  
> current design
> because >visitation thru a tree was going to go to every node  
> regardless of
> lifecycle strategy >choices for each node.  I.e. if you wanted to  
> block
> traversal at some scope, you >could not.  Seems to me that a  
> container should be
> able to block a number of things >its parent is trying to do to it.
>
> Yeah, I remember that stuff.
>
> If I have the time when Pico 3 rolls around, I'll see about  
> expanding from
> there.
>
> -Mike
>
> P.S. For any lurkers out there, no we aren't even really THINKING  
> about Pico 3
> yet! :)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

OK Mike, I can apply the patch (after two small manual applications to  
two files) and it builds and passes tests.

visitContainer(PicoContainer) returning true begs a question:

"Any visitor callback that returns ABORT_TRAVERSAL indicates the  
desire to abort any further traversal"

Does that mean traversal just halts at the current visitation, or is  
not allowed to go deeper than the current 'container depth' ?

- Paul

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

And  Mike the testcase that shows use of ABORT_TRAVERSAL does not  
really explain why a person would use it.

What's the real world scenario ?

- Paul

On Jun 21, 2008, at 12:36 PM, Paul Hammant wrote:

> OK Mike, I can apply the patch (after two small manual applications  
> to two files) and it builds and passes tests.
>
> visitContainer(PicoContainer) returning true begs a question:
>
> "Any visitor callback that returns ABORT_TRAVERSAL indicates the  
> desire to abort any further traversal"
>
> Does that mean traversal just halts at the current visitation, or is  
> not allowed to go deeper than the current 'container depth' ?
>
> - Paul
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Michael Rimov]

 

> OK Mike, I can apply the patch (after two small manual applications to
> two files) and it builds and passes tests.
>
> visitContainer(PicoContainer) returning true begs a question:
>
> "Any visitor callback that returns ABORT_TRAVERSAL indicates the
> desire to abort any further traversal"
>
> Does that mean traversal just halts at the current visitation, or is
> not allowed to go deeper than the current 'container depth' ?

Well, ideally it would halt.  However, without changing PicoContainer.accept(),
it is impossible to truly do an instantaneous halt.  In particular, if DPC is
iterating the child containers, and while visiting one of the child containers,
the visitor calls ABORT_TRAVERSAL, then DPC will keep iterating the child
containers.

So the visitor will need to keep returning ABORT_TRAVERSAL multiple times.

However, it is at least guaranteed at this point that if visitContainer()
returns ABORT_TRAVERSAL, then none of the container's CAFs, CAs, nor child
containers will be visited.

Hokey?  Absolutely.

Would I modify every accept() method in the pico library to return a boolean
value to allow instantaneous guaranteed aborting of the traversal?  Yup.  

Do I think it would be appropriate at this stage in the 2.0 release cycle to do
so?  Nope :)  I think it would force too many API changes.  (It would affect
CA, CAFs, and PicoContainer interfaces)

                                                                -Mike




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Paul Hammant-3]

maybe it should be tri-state...

HALT_IMMEDIATELY, KEEP_GOING, and NO_DEEPER

Or that might not be possible as you say.

- Paul


On Jun 21, 2008, at 2:03 PM, Michael Rimov wrote:

>
>> OK Mike, I can apply the patch (after two small manual applications  
>> to
>> two files) and it builds and passes tests.
>>
>> visitContainer(PicoContainer) returning true begs a question:
>>
>> "Any visitor callback that returns ABORT_TRAVERSAL indicates the
>> desire to abort any further traversal"
>>
>> Does that mean traversal just halts at the current visitation, or is
>> not allowed to go deeper than the current 'container depth' ?
>
> Well, ideally it would halt.  However, without changing  
> PicoContainer.accept(),
> it is impossible to truly do an instantaneous halt.  In particular,  
> if DPC is
> iterating the child containers, and while visiting one of the child  
> containers,
> the visitor calls ABORT_TRAVERSAL, then DPC will keep iterating the  
> child
> containers.
>
> So the visitor will need to keep returning ABORT_TRAVERSAL multiple  
> times.
>
> However, it is at least guaranteed at this point that if  
> visitContainer()
> returns ABORT_TRAVERSAL, then none of the container's CAFs, CAs, nor  
> child
> containers will be visited.
>
> Hokey?  Absolutely.
>
> Would I modify every accept() method in the pico library to return a  
> boolean
> value to allow instantaneous guaranteed aborting of the traversal?  
> Yup.
>
> Do I think it would be appropriate at this stage in the 2.0 release  
> cycle to do
> so?  Nope :)  I think it would force too many API changes.  (It  
> would affect
> CA, CAFs, and PicoContainer interfaces)
>
> -Mike
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Michael Rimov]

> maybe it should be tri-state...
>
> HALT_IMMEDIATELY, KEEP_GOING, and NO_DEEPER
>
> Or that might not be possible as you say.

Correct, right now it isn't possible.  But I'll file a Jira issue on it for Pico
3 so we can revisit in later.  Sorry to keep bringing things up like this now
that Pico 2 is nicely set in stone... I was just knee deep in projects at that
point and couldn't come up for air.

                                                                -Mike



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Jörg Schaible-2]

Paul Hammant wrote:

> Mike,
>
> So its funny Aslak reworked the lifecycle stuff to use a visitor some
> years ago. I ended up removing it and going back to essentially the
> current design because visitation thru a tree was going to go to every
> node regardless of lifecycle strategy choices for each node.  I.e. if
> you wanted to block traversal at some scope, you could not.  Seems to
> me that a container should be able to block a number of things its
> parent is trying to do to it.
>
> So if you were interested there is in Svn (deleted) a LifecycleVisitor.

The main problem was stop/dispose, since they need a visitor visiting the
elements in reverse order ... ;-)

- Jörg


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email