[chain] Serializability of base impls

[Rahul Akolkar <ra...@gmail.com>]

Recently, while looking at a codebase that uses Commons Chain, I was
drawn to the top commit message for ContextBase [1].

I'm interested in knowing what the developer (and user too) opinions
are on this topic. Has anybody made any progress on this?

Does anyone have a preference among -

 * Keep base impls inherently serializable, but let subclass
implementors make their own decisions about serializability. This is
probably a good idea for any Commons library, since interfaces can't
be "un-inherited" (quoting the commit message). I think this action
will warrant a major release, and rework on ContextBase (to not
inherit HashMap) amongst other things.

 * Mark an issue in the [chain] release notes

 * Do nothing at all

 * Some other suggestion

-Rahul

[1] http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/chain/trunk/src/java/org/apache/commons/chain/impl/ContextBase.java

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [chain] Serializability of base impls

[Rahul Akolkar <ra...@gmail.com>]

On 11/30/05, Niall Pemberton <ni...@gmail.com> wrote:
> On 11/30/05, Rahul Akolkar <ra...@gmail.com> wrote:
> > Recently, while looking at a codebase that uses Commons Chain, I was
> > drawn to the top commit message for ContextBase [1].
> >
> > I'm interested in knowing what the developer (and user too) opinions
> > are on this topic. Has anybody made any progress on this?
> >
> > Does anyone have a preference among -
> >
> >  * Keep base impls inherently serializable, but let subclass
> > implementors make their own decisions about serializability. This is
> > probably a good idea for any Commons library, since interfaces can't
> > be "un-inherited" (quoting the commit message). I think this action
> > will warrant a major release, and rework on ContextBase (to not
> > inherit HashMap) amongst other things.
>
> Whats wrong with HashMap - it implements Serializable?
>
<snip/>

Yes, and the subsequent implication that has on all subclasses. This
already affects (Servlet / Portlet / Faces) WebContext classes in
[chain]; but more importantly it can also affect users of Commons
Chain the same way.

"Affect" -- that is, only if you believe that classes should advertise
serializability if and *only if* they are serializable. Usage wise,
the argument can be easily made that if one is never going to attempt
to serialize a class instance, then it really doesn't matter even if
its advertised as serializable and isn't (because you'll never know
any better). For that school of thought, I had presented the third
bullet "Do nothing at all".

-Rahul


>
> Niall
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

Re: [chain] Serializability of base impls

[Niall Pemberton <ni...@gmail.com>]

On 11/30/05, Rahul Akolkar <ra...@gmail.com> wrote:
> Recently, while looking at a codebase that uses Commons Chain, I was
> drawn to the top commit message for ContextBase [1].
>
> I'm interested in knowing what the developer (and user too) opinions
> are on this topic. Has anybody made any progress on this?
>
> Does anyone have a preference among -
>
>  * Keep base impls inherently serializable, but let subclass
> implementors make their own decisions about serializability. This is
> probably a good idea for any Commons library, since interfaces can't
> be "un-inherited" (quoting the commit message). I think this action
> will warrant a major release, and rework on ContextBase (to not
> inherit HashMap) amongst other things.

Whats wrong with HashMap - it implements Serializable?

Niall

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org