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
#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
- imple
> #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
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 loo
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
re
