>
> As long as you are willing to go this far, it would be nice if there were
> an immutable reference type that could be produced by a builder class. It's
> easier to reason about the thread-safety of code involving immutable types,
> and the ability to modify a reference once it's built doesn't seem a common
> requirement. The current Reference class with its mutative methods could
> remain for compatibility, maybe implementing a non-mutative interface, e.g.,
> ResourceRef (produced by ResourceRefBuilder).
I believe that having the ReferenceBuilder generate URI strings obviates the
need for a separate immutable class.
Isn't the most common use case just generating a URI and passing it to the
Client in order to connect?
On Dec 4, 2007 10:33 AM, Tim Peierls <[EMAIL PROTECTED]> wrote:
> On Dec 4, 2007 9:50 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:
>
> > Again, if the performance isn't an issue, we could simply implement the
> > methods this way (+ NPE checks) :
> >
> > public void addQueryParameter(String name, String value) {
> > setQuery(getQuery() + '&' + encode(name) + '=' + encode(value));
> > }
> >
> > In addition, we could still add a fluent ReferenceBuilder, which would
> > be stricter about the ordering but much faster as one single buffer would be
> > necessary (with a status int flag).
> >
>
> As long as you are willing to go this far, it would be nice if there were
> an immutable reference type that could be produced by a builder class. It's
> easier to reason about the thread-safety of code involving immutable types,
> and the ability to modify a reference once it's built doesn't seem a common
> requirement. The current Reference class with its mutative methods could
> remain for compatibility, maybe implementing a non-mutative interface, e.g.,
> ResourceRef (produced by ResourceRefBuilder).
>
> --tim
>
