On Mon, Jul 28, 2008 at 10:47 AM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> r678354 added yet another mutator to HttpResponse. Kevin suggested
> that this is less than ideal:
>
> -----------
> Why add a new method for this instead of passing the headers in the ctor?
> HttpResponse is already very problematic, as it should be immutable, but we
> keep adding mutators to it. It's very hard to implement a cache of objects
> when the data in the cache can be modified, and as a result most caches
> have
> to be written more defensively than necessary, with copies being produced
> on
> every read.
> -----------
>
> We keep adding mutators to it because it's a serious pain to construct
> objects using umpteen different parameters, especially when all of
> those parameters are strings. I feel your pain about it's lack of
> immutability, though. I'm not sure of the best way to handle this.
> Maybe a freeze() method that marks the object as immutable at some
> point after contruction? Maybe bite the bullet, declare it really
> truly immutable, and forbid attempts to make it otherwise?
How about HttpResponseBuilder? I'd much rather have:
HttpResponse response = new HttpResponseBuilder()
.setStatus(HttpResponse.SC_OK)
.setBody("foo")
.setContentType("text/plain")
.setCacheControl("public", 3600)
.create();
than what we have today.
Doubly so for requests, which require even more forming.
We don't have to pass 15 parameters in the ctor -- we just need to fix the
whole thing.
The immutability is primarily of interest for caching. You can get away
without it, but having a mix of some stuff passed in the ctor and a bunch of
other stuff set as setters (many of which are borderline mandatory) is very
awkward to work with.
> HTTP responses are complicated beasts. I don't know of any
> programming framework that tries to make them immutable, it's just too
> annoying to work with.
>
> Cheers,
> Brian
>
