You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2004/04/06 21:56:59 UTC
[collections] Serializable decorators
I had a look at making the decorators serializable, and it will take some
time (tedious mostly). However I did find a design decision.
The collection that a decorator decorates may or may not be serializable.
But does the decorator need to represent this? This leads to two options.
1) Make all decorators implement serializable, but some will fail at runtime
if you decorate a non-serializable instance.
2) Implement serializable subclasses of each decorator, and use the factory
method to create either the serializable or non-serializable subclass as
required.
#1 is easy, #2 will take much longer. Any views? #1 is the default choice.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Serializable decorators
Posted by "matthew.hawthorne" <ma...@apache.org>.
Stephen Colebourne wrote:
> 1) Make all decorators implement serializable, but some will fail at runtime
> if you decorate a non-serializable instance.
>
> 2) Implement serializable subclasses of each decorator, and use the factory
> method to create either the serializable or non-serializable subclass as
> required.
>
> #1 is easy, #2 will take much longer. Any views? #1 is the default choice.
I like #1 also. It just seems easier.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
RE: [collections] Serializable decorators
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen Colebourne wrote:
> #1 is sufficient IMO.
> #2 leads to scary places.
Well, since you've spent more time looking at this than I have, and I don't
have any strong reason to disagree, I'd go with your approach. :-)
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Serializable decorators
Posted by Stephen Colebourne <sc...@btopenworld.com>.
#1 is sufficient IMO.
#2 leads to scary places. For example, collections should really have a
JDK1.4 version that has decorators that add the RandomAccess interface as
appropriate. To achieve that and a serializable interface would require 4
classes:
- implements RandomAccess, Serializable
- implements RandomAccess
- implements Serializable
- none
Since serializable isn't typically checked by programs, it seems OK to
choose #1.
Stephen
From: "Noel J. Bergman" <no...@devtech.com>
> > #1 is easy, #2 will take much longer.
>
> I am short on time today, so I haven't given either much thought. But
since
> you have, let me ask you this: which way do you feel would be best for the
> long term of the project? Which is most consistent and "natural", if
> either?
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> 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] Serializable decorators
Posted by "Noel J. Bergman" <no...@devtech.com>.
> #1 is easy, #2 will take much longer.
I am short on time today, so I haven't given either much thought. But since
you have, let me ask you this: which way do you feel would be best for the
long term of the project? Which is most consistent and "natural", if
either?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [collections] Serializable decorators
Posted by Michael Heuer <he...@acm.org>.
non-binding +1 to #1.
All the wrapper methods in java.util.Collections note
The returned xxx will be serializable if the specified xxx is
serializable.
in their javadocs and the wrapper classes appear follow this design.
michael
On Tue, 6 Apr 2004, Stephen Colebourne wrote:
> I had a look at making the decorators serializable, and it will take some
> time (tedious mostly). However I did find a design decision.
>
> The collection that a decorator decorates may or may not be serializable.
> But does the decorator need to represent this? This leads to two options.
>
> 1) Make all decorators implement serializable, but some will fail at runtime
> if you decorate a non-serializable instance.
>
> 2) Implement serializable subclasses of each decorator, and use the factory
> method to create either the serializable or non-serializable subclass as
> required.
>
> #1 is easy, #2 will take much longer. Any views? #1 is the default choice.
>
> Stephen
>
>
> ---------------------------------------------------------------------
> 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