added o.a.asyncweb.common.codec and Mutable interfaces

[jv...@archean.fr]

Hi,

I moved some class related to HTTP message encoding/decoding from
o.a.asyncweb.common to o.a.asynweb.common.codec. So there is less crowd in
the package.

I thought about another simplification :

for a simple Http Message you have this heritance tree :

DefaultHttpResponse extends DefaultHttpMessage
       implements MutableHttpResponse

DefaultHttpMessage implements MutableHttpMessage
MutableHttpMessage extends HttpMessage

MutableHttpResponse extends MutableHttpMessage, HttpResponse
HttpResponse extends HttpMessage
MutableHttpMessage extends HttpMessage

As far as I understand it, fr http messages the interfaces was splited in
two, the getters and the setters (mutable part). After looking around I
see no real utilisation for that since all the conrecte implemenations are
Mutables.

By removing the Mutable interface we will greatly simplify the structure
of those messages.

WDYT ?

Julien

Re: added o.a.asyncweb.common.codec and Mutable interfaces

[Maarten Bosteels <mb...@gmail.com>]

Hi,


On Thu, Jul 3, 2008 at 11:28 PM, <jv...@archean.fr> wrote:

> Hi,
>
> I moved some class related to HTTP message encoding/decoding from
> o.a.asyncweb.common to o.a.asynweb.common.codec. So there is less crowd in
> the package.
>
> I thought about another simplification :
>
> for a simple Http Message you have this heritance tree :
>
> DefaultHttpResponse extends DefaultHttpMessage
>       implements MutableHttpResponse
>
> DefaultHttpMessage implements MutableHttpMessage
> MutableHttpMessage extends HttpMessage
>
> MutableHttpResponse extends MutableHttpMessage, HttpResponse
> HttpResponse extends HttpMessage
> MutableHttpMessage extends HttpMessage
>
> As far as I understand it, fr http messages the interfaces was splited in
> two, the getters and the setters (mutable part). After looking around I
> see no real utilisation for that since all the conrecte implemenations are
> Mutables.


Firts, I must admit that I have zero experience with these classes, and
haven't looked at the code.
But in general, the distinction between mutable and immutable can have a big
documenting benefit.

When a method takes an immutable parameter, you can assume that the method
won't change the state of the object (of course, the method could cast the
parameter to the Mutable concrete class, but that would be a total
disgrace).

Maarten


>
>
> By removing the Mutable interface we will greatly simplify the structure
> of those messages.
>
> WDYT ?
>
> Julien
>
>