You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rodney Waldhoff <rw...@apache.org> on 2003/09/18 19:03:54 UTC
[collections] deprecate CursorableLinkedList?
If there are no complaints, I'd like to deprecate CursorableLinkedList for
the 3.0 collections release, to be removed in the 4.0 release.
CursorableLinkedList provides a List implementation that supports a type
of Iterator (called a Cursor) that isn't bothered by concurrent
modifications--you can safely add or remove items before or after the
current location of the cursor and the cursor will simply see the current
status of the list when it gets there.
While this functionality works fine, it's too complicated by half, and
there are bugs in other areas of the interface (well, the only bug I'm
aware of is that it isn't really Serializable, despite what the interface
claims.)
I suspect that commons-pool is the only consumer of this class, where it
is used to walk through the set of pooled objects while borrowObject or
returnObjct calls may asynchronously modify the underlying list. By
deprecating (and eventually removing) this class, we could either move
CursorableLinkedList over to pool, or (my preference) replace the
CursorableLinkedList with a significantly simpler but slightly less
predictable approach (like iterating via list.get(counter++%list.size()),
but that's a topic for another thread.
Contrariwise, if we'd like to keep CursorableLinkedList, we should either
fix the Serialization or remove the "implements Serializable" part of the
class declaration.
- Rod <http://radio.weblogs.com/0122027/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] deprecate CursorableLinkedList?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 18 Sep 2003, Rodney Waldhoff wrote:
> Date: Thu, 18 Sep 2003 10:03:54 -0700 (PDT)
> From: Rodney Waldhoff <rw...@apache.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: commons-dev@jakarta.apache.org
> Subject: [collections] deprecate CursorableLinkedList?
>
> If there are no complaints, I'd like to deprecate CursorableLinkedList for
> the 3.0 collections release, to be removed in the 4.0 release.
>
> CursorableLinkedList provides a List implementation that supports a type
> of Iterator (called a Cursor) that isn't bothered by concurrent
> modifications--you can safely add or remove items before or after the
> current location of the cursor and the cursor will simply see the current
> status of the list when it gets there.
>
> While this functionality works fine, it's too complicated by half, and
> there are bugs in other areas of the interface (well, the only bug I'm
> aware of is that it isn't really Serializable, despite what the interface
> claims.)
>
> I suspect that commons-pool is the only consumer of this class, where it
> is used to walk through the set of pooled objects while borrowObject or
> returnObjct calls may asynchronously modify the underlying list. By
> deprecating (and eventually removing) this class, we could either move
> CursorableLinkedList over to pool, or (my preference) replace the
> CursorableLinkedList with a significantly simpler but slightly less
> predictable approach (like iterating via list.get(counter++%list.size()),
> but that's a topic for another thread.
>
> Contrariwise, if we'd like to keep CursorableLinkedList, we should either
> fix the Serialization or remove the "implements Serializable" part of the
> class declaration.
>
I'm a happy user of CursorableLinkedList in a couple of scenarios where
you want to process a series of events, and the event handlers can insert
or remove events from the queue while you're iterating. It's quite handy,
so this is a nonbinding -1 on deprecating/removing it.
I have no problem with removing "implements Serializable" though, because
I do not rely on being able to persist instances.
> - Rod <http://radio.weblogs.com/0122027/>
>
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] deprecate CursorableLinkedList?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
This class has been changed, and should now be fully Serializable. (Open
cursors are not now serialized)
Stephen
----- Original Message -----
From: "Simon Kitching" <si...@ecnetwork.co.nz>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, September 18, 2003 10:41 PM
Subject: Re: [collections] deprecate CursorableLinkedList?
> On Fri, 2003-09-19 at 09:38, Rodney Waldhoff wrote:
> > Since both Craig and you have expressed an interest in keeping this
class
> > around, I'm more than happy to leave it.
> >
> > Let's remove "implements Serializable" for the 3.0 release, unless
someone
> > feels like making it work (probably a missing a "transient" somewhere).
>
> Removing Serializable would be fine for my purposes; I don't need that
> functionality.
>
> Thanks.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
Re: [collections] deprecate CursorableLinkedList?
Posted by Stephen Colebourne <sc...@btopenworld.com>.
This class has been changed, and should now be fully Serializable. (Open
cursors are not now serialized)
Stephen
----- Original Message -----
From: "Simon Kitching" <si...@ecnetwork.co.nz>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, September 18, 2003 10:41 PM
Subject: Re: [collections] deprecate CursorableLinkedList?
> On Fri, 2003-09-19 at 09:38, Rodney Waldhoff wrote:
> > Since both Craig and you have expressed an interest in keeping this
class
> > around, I'm more than happy to leave it.
> >
> > Let's remove "implements Serializable" for the 3.0 release, unless
someone
> > feels like making it work (probably a missing a "transient" somewhere).
>
> Removing Serializable would be fine for my purposes; I don't need that
> functionality.
>
> Thanks.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] deprecate CursorableLinkedList?
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Fri, 2003-09-19 at 09:38, Rodney Waldhoff wrote:
> Since both Craig and you have expressed an interest in keeping this class
> around, I'm more than happy to leave it.
>
> Let's remove "implements Serializable" for the 3.0 release, unless someone
> feels like making it work (probably a missing a "transient" somewhere).
Removing Serializable would be fine for my purposes; I don't need that
functionality.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] deprecate CursorableLinkedList?
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Fri, 2003-09-19 at 09:38, Rodney Waldhoff wrote:
> Since both Craig and you have expressed an interest in keeping this class
> around, I'm more than happy to leave it.
>
> Let's remove "implements Serializable" for the 3.0 release, unless someone
> feels like making it work (probably a missing a "transient" somewhere).
Removing Serializable would be fine for my purposes; I don't need that
functionality.
Thanks.
Re: [collections] deprecate CursorableLinkedList?
Posted by Rodney Waldhoff <rw...@apache.org>.
Since both Craig and you have expressed an interest in keeping this class
around, I'm more than happy to leave it.
Let's remove "implements Serializable" for the 3.0 release, unless someone
feels like making it work (probably a missing a "transient" somewhere).
On Thu, 19 Sep 2003, Simon Kitching wrote:
> On Fri, 2003-09-19 at 05:03, Rodney Waldhoff wrote:
> > If there are no complaints, I'd like to deprecate CursorableLinkedList for
> > the 3.0 collections release, to be removed in the 4.0 release.
>
> Bugger. I was just intending to propose using this class from within
> commons-digester.
>
> It would be no big deal I guess to have a "private" implementation of
> this functionality (or some subset thereof). Still, it would be nice if
> the class was available in commons-collections.
>
> Cheers,
>
> Simon
>
--
- Rod <http://radio.weblogs.com/0122027/>
Re: [collections] deprecate CursorableLinkedList?
Posted by Rodney Waldhoff <rw...@apache.org>.
Since both Craig and you have expressed an interest in keeping this class
around, I'm more than happy to leave it.
Let's remove "implements Serializable" for the 3.0 release, unless someone
feels like making it work (probably a missing a "transient" somewhere).
On Thu, 19 Sep 2003, Simon Kitching wrote:
> On Fri, 2003-09-19 at 05:03, Rodney Waldhoff wrote:
> > If there are no complaints, I'd like to deprecate CursorableLinkedList for
> > the 3.0 collections release, to be removed in the 4.0 release.
>
> Bugger. I was just intending to propose using this class from within
> commons-digester.
>
> It would be no big deal I guess to have a "private" implementation of
> this functionality (or some subset thereof). Still, it would be nice if
> the class was available in commons-collections.
>
> Cheers,
>
> Simon
>
--
- Rod <http://radio.weblogs.com/0122027/>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [collections] deprecate CursorableLinkedList?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Bugger. I was just intending to propose using this class from within
> commons-digester.
So just say so. That sounds like two -1's from people who want to use it.
--- Noel
RE: [collections] deprecate CursorableLinkedList?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Bugger. I was just intending to propose using this class from within
> commons-digester.
So just say so. That sounds like two -1's from people who want to use it.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] deprecate CursorableLinkedList?
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Fri, 2003-09-19 at 05:03, Rodney Waldhoff wrote:
> If there are no complaints, I'd like to deprecate CursorableLinkedList for
> the 3.0 collections release, to be removed in the 4.0 release.
Bugger. I was just intending to propose using this class from within
commons-digester.
It would be no big deal I guess to have a "private" implementation of
this functionality (or some subset thereof). Still, it would be nice if
the class was available in commons-collections.
Cheers,
Simon
Re: [collections] deprecate CursorableLinkedList?
Posted by ja...@carmanconsulting.com.
Nevermind, RTFM. Sorry, folks.
----- Original Message -----
From: <ja...@carmanconsulting.com>
To: <co...@jakarta.apache.org>
Sent: Thursday, September 18, 2003 1:07 PM
Subject: Re: [collections] deprecate CursorableLinkedList?
> If I append something asynchronously to the end of the list while a Cursor
> is open, will the cursor pick that up? Or, does a cursor merely take a
> snap-shot of the underlying list and iterate over whatever is there
> currently? Just curious.
>
> ----- Original Message -----
> From: "Rodney Waldhoff" <rw...@apache.org>
> To: <co...@jakarta.apache.org>
> Sent: Thursday, September 18, 2003 1:03 PM
> Subject: [collections] deprecate CursorableLinkedList?
>
>
> > If there are no complaints, I'd like to deprecate CursorableLinkedList
for
> > the 3.0 collections release, to be removed in the 4.0 release.
> >
> > CursorableLinkedList provides a List implementation that supports a type
> > of Iterator (called a Cursor) that isn't bothered by concurrent
> > modifications--you can safely add or remove items before or after the
> > current location of the cursor and the cursor will simply see the
current
> > status of the list when it gets there.
> >
> > While this functionality works fine, it's too complicated by half, and
> > there are bugs in other areas of the interface (well, the only bug I'm
> > aware of is that it isn't really Serializable, despite what the
interface
> > claims.)
> >
> > I suspect that commons-pool is the only consumer of this class, where it
> > is used to walk through the set of pooled objects while borrowObject or
> > returnObjct calls may asynchronously modify the underlying list. By
> > deprecating (and eventually removing) this class, we could either move
> > CursorableLinkedList over to pool, or (my preference) replace the
> > CursorableLinkedList with a significantly simpler but slightly less
> > predictable approach (like iterating via
list.get(counter++%list.size()),
> > but that's a topic for another thread.
> >
> > Contrariwise, if we'd like to keep CursorableLinkedList, we should
either
> > fix the Serialization or remove the "implements Serializable" part of
the
> > class declaration.
> >
> > - Rod <http://radio.weblogs.com/0122027/>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
Re: [collections] deprecate CursorableLinkedList?
Posted by Rodney Waldhoff <rw...@apache.org>.
On Thu, 18 Sep 2003 james@carmanconsulting.com wrote:
> If I append something asynchronously to the end of the list while a Cursor
> is open, will the cursor pick that up?
Yes.
> Or, does a cursor merely take a
> snap-shot of the underlying list and iterate over whatever is there
> currently?
No. Not a snapshot. If I remember correctly, CursorableLinkedList is a
doubly linked list. The cursor maintains a reference to some node in that
list. If you muck around with any other node, the Cursor doesn't care,
indeed it doesn't really know. The only tricky bit is when you want to
remove the node that the cursor is currently sitting on, in which case the
cursor slides forward.
> Just curious.
Sure. No problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] deprecate CursorableLinkedList?
Posted by ja...@carmanconsulting.com.
Nevermind, RTFM. Sorry, folks.
----- Original Message -----
From: <ja...@carmanconsulting.com>
To: <co...@jakarta.apache.org>
Sent: Thursday, September 18, 2003 1:07 PM
Subject: Re: [collections] deprecate CursorableLinkedList?
> If I append something asynchronously to the end of the list while a Cursor
> is open, will the cursor pick that up? Or, does a cursor merely take a
> snap-shot of the underlying list and iterate over whatever is there
> currently? Just curious.
>
> ----- Original Message -----
> From: "Rodney Waldhoff" <rw...@apache.org>
> To: <co...@jakarta.apache.org>
> Sent: Thursday, September 18, 2003 1:03 PM
> Subject: [collections] deprecate CursorableLinkedList?
>
>
> > If there are no complaints, I'd like to deprecate CursorableLinkedList
for
> > the 3.0 collections release, to be removed in the 4.0 release.
> >
> > CursorableLinkedList provides a List implementation that supports a type
> > of Iterator (called a Cursor) that isn't bothered by concurrent
> > modifications--you can safely add or remove items before or after the
> > current location of the cursor and the cursor will simply see the
current
> > status of the list when it gets there.
> >
> > While this functionality works fine, it's too complicated by half, and
> > there are bugs in other areas of the interface (well, the only bug I'm
> > aware of is that it isn't really Serializable, despite what the
interface
> > claims.)
> >
> > I suspect that commons-pool is the only consumer of this class, where it
> > is used to walk through the set of pooled objects while borrowObject or
> > returnObjct calls may asynchronously modify the underlying list. By
> > deprecating (and eventually removing) this class, we could either move
> > CursorableLinkedList over to pool, or (my preference) replace the
> > CursorableLinkedList with a significantly simpler but slightly less
> > predictable approach (like iterating via
list.get(counter++%list.size()),
> > but that's a topic for another thread.
> >
> > Contrariwise, if we'd like to keep CursorableLinkedList, we should
either
> > fix the Serialization or remove the "implements Serializable" part of
the
> > class declaration.
> >
> > - Rod <http://radio.weblogs.com/0122027/>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] deprecate CursorableLinkedList?
Posted by Rodney Waldhoff <rw...@apache.org>.
On Thu, 18 Sep 2003 james@carmanconsulting.com wrote:
> If I append something asynchronously to the end of the list while a Cursor
> is open, will the cursor pick that up?
Yes.
> Or, does a cursor merely take a
> snap-shot of the underlying list and iterate over whatever is there
> currently?
No. Not a snapshot. If I remember correctly, CursorableLinkedList is a
doubly linked list. The cursor maintains a reference to some node in that
list. If you muck around with any other node, the Cursor doesn't care,
indeed it doesn't really know. The only tricky bit is when you want to
remove the node that the cursor is currently sitting on, in which case the
cursor slides forward.
> Just curious.
Sure. No problem.
Re: [collections] deprecate CursorableLinkedList?
Posted by ja...@carmanconsulting.com.
If I append something asynchronously to the end of the list while a Cursor
is open, will the cursor pick that up? Or, does a cursor merely take a
snap-shot of the underlying list and iterate over whatever is there
currently? Just curious.
----- Original Message -----
From: "Rodney Waldhoff" <rw...@apache.org>
To: <co...@jakarta.apache.org>
Sent: Thursday, September 18, 2003 1:03 PM
Subject: [collections] deprecate CursorableLinkedList?
> If there are no complaints, I'd like to deprecate CursorableLinkedList for
> the 3.0 collections release, to be removed in the 4.0 release.
>
> CursorableLinkedList provides a List implementation that supports a type
> of Iterator (called a Cursor) that isn't bothered by concurrent
> modifications--you can safely add or remove items before or after the
> current location of the cursor and the cursor will simply see the current
> status of the list when it gets there.
>
> While this functionality works fine, it's too complicated by half, and
> there are bugs in other areas of the interface (well, the only bug I'm
> aware of is that it isn't really Serializable, despite what the interface
> claims.)
>
> I suspect that commons-pool is the only consumer of this class, where it
> is used to walk through the set of pooled objects while borrowObject or
> returnObjct calls may asynchronously modify the underlying list. By
> deprecating (and eventually removing) this class, we could either move
> CursorableLinkedList over to pool, or (my preference) replace the
> CursorableLinkedList with a significantly simpler but slightly less
> predictable approach (like iterating via list.get(counter++%list.size()),
> but that's a topic for another thread.
>
> Contrariwise, if we'd like to keep CursorableLinkedList, we should either
> fix the Serialization or remove the "implements Serializable" part of the
> class declaration.
>
> - Rod <http://radio.weblogs.com/0122027/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
Re: [collections] deprecate CursorableLinkedList?
Posted by ja...@carmanconsulting.com.
If I append something asynchronously to the end of the list while a Cursor
is open, will the cursor pick that up? Or, does a cursor merely take a
snap-shot of the underlying list and iterate over whatever is there
currently? Just curious.
----- Original Message -----
From: "Rodney Waldhoff" <rw...@apache.org>
To: <co...@jakarta.apache.org>
Sent: Thursday, September 18, 2003 1:03 PM
Subject: [collections] deprecate CursorableLinkedList?
> If there are no complaints, I'd like to deprecate CursorableLinkedList for
> the 3.0 collections release, to be removed in the 4.0 release.
>
> CursorableLinkedList provides a List implementation that supports a type
> of Iterator (called a Cursor) that isn't bothered by concurrent
> modifications--you can safely add or remove items before or after the
> current location of the cursor and the cursor will simply see the current
> status of the list when it gets there.
>
> While this functionality works fine, it's too complicated by half, and
> there are bugs in other areas of the interface (well, the only bug I'm
> aware of is that it isn't really Serializable, despite what the interface
> claims.)
>
> I suspect that commons-pool is the only consumer of this class, where it
> is used to walk through the set of pooled objects while borrowObject or
> returnObjct calls may asynchronously modify the underlying list. By
> deprecating (and eventually removing) this class, we could either move
> CursorableLinkedList over to pool, or (my preference) replace the
> CursorableLinkedList with a significantly simpler but slightly less
> predictable approach (like iterating via list.get(counter++%list.size()),
> but that's a topic for another thread.
>
> Contrariwise, if we'd like to keep CursorableLinkedList, we should either
> fix the Serialization or remove the "implements Serializable" part of the
> class declaration.
>
> - Rod <http://radio.weblogs.com/0122027/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] deprecate CursorableLinkedList?
Posted by Simon Kitching <si...@ecnetwork.co.nz>.
On Fri, 2003-09-19 at 05:03, Rodney Waldhoff wrote:
> If there are no complaints, I'd like to deprecate CursorableLinkedList for
> the 3.0 collections release, to be removed in the 4.0 release.
Bugger. I was just intending to propose using this class from within
commons-digester.
It would be no big deal I guess to have a "private" implementation of
this functionality (or some subset thereof). Still, it would be nice if
the class was available in commons-collections.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] deprecate CursorableLinkedList?
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 18 Sep 2003, Rodney Waldhoff wrote:
> Date: Thu, 18 Sep 2003 10:03:54 -0700 (PDT)
> From: Rodney Waldhoff <rw...@apache.org>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: commons-dev@jakarta.apache.org
> Subject: [collections] deprecate CursorableLinkedList?
>
> If there are no complaints, I'd like to deprecate CursorableLinkedList for
> the 3.0 collections release, to be removed in the 4.0 release.
>
> CursorableLinkedList provides a List implementation that supports a type
> of Iterator (called a Cursor) that isn't bothered by concurrent
> modifications--you can safely add or remove items before or after the
> current location of the cursor and the cursor will simply see the current
> status of the list when it gets there.
>
> While this functionality works fine, it's too complicated by half, and
> there are bugs in other areas of the interface (well, the only bug I'm
> aware of is that it isn't really Serializable, despite what the interface
> claims.)
>
> I suspect that commons-pool is the only consumer of this class, where it
> is used to walk through the set of pooled objects while borrowObject or
> returnObjct calls may asynchronously modify the underlying list. By
> deprecating (and eventually removing) this class, we could either move
> CursorableLinkedList over to pool, or (my preference) replace the
> CursorableLinkedList with a significantly simpler but slightly less
> predictable approach (like iterating via list.get(counter++%list.size()),
> but that's a topic for another thread.
>
> Contrariwise, if we'd like to keep CursorableLinkedList, we should either
> fix the Serialization or remove the "implements Serializable" part of the
> class declaration.
>
I'm a happy user of CursorableLinkedList in a couple of scenarios where
you want to process a series of events, and the event handlers can insert
or remove events from the queue while you're iterating. It's quite handy,
so this is a nonbinding -1 on deprecating/removing it.
I have no problem with removing "implements Serializable" though, because
I do not rely on being able to persist instances.
> - Rod <http://radio.weblogs.com/0122027/>
>
Craig McClanahan