Re: [httpclient] API design, Cookie.getExpiryDate, Cookie.setExpiryDate

["Sean C. Sullivan" <se...@seansullivan.com>]

My comments are below...

From: "dIon Gillard" <di...@multitask.com.au>
> Sean C. Sullivan wrote:
>
> >I updated the code for the HttpClient:
> >
> >        Cookie.java
> >        TestCookie.java
> >
> >
> >The modification changes the behavior of Cookie.getExpiryDate
> >
> >Instead of returning the internal Date object, we return a freshly
> >instantiated Date object.
> >
> >Why:    Because java.util.Date is a mutable object.
> >
> >I created the patch files using this command:
> >
> >             cvs diff -c Foo.java > Foo.patch
> >
> > -Sean
> >
>
> I'm not sure that the original behaviour is flawed as coded.
>
> The patch implies that passing setExpiryDate a Date object and then
> changing that object is a 'bad thing'. But this is the existing
> behaviour, so under the current code, I can do this:
> // uncompiled untested code
> Date d = new Date();
> cookie.setExpiryDate(d);
> d.setTime(System.currentTimeMillis());
>
> and based on the current code set, I expect the expiry date of the
> cookie to have changed. And ditto, on calling getExpiryDate() I expect
> to be able to change the Date and have it reflected in the cookie.
>
> The patch is effectively a change in the implied contract between httpclient
and the user....Comments?

I would like the HttpClient API to follow the API guidelines from Josh Bloch's
book:

  Effective Java Programming Language Guide
   http://www.amazon.com/exec/obidos/ASIN/0201310058/


Josh Bloch is a Senior Software Architect at Sun.  Josh designed
the Java Collections API.

I highly recommend Josh's book.

In particular, I like these guidelines from Bloch's book:

==> Item 13:  Favor immutability  (immutable objects)

==> Item 12: Minimize the accessibility of classes and members

==> Item 6: Avoid finalizers

==> Item 21: Replace enum constructs with classes

==> Item 54: implement java.io.Serializable judiciously

==> Item 9:  Always override toString()

==> Item 10: Override clone judiciously

==> Item 15: Design and document for inheritance or else prohibit it

==> Item 17: Use interfaces only to define types

==> Item 23: Check parameters for validity

==> Item 24: Make defensive copies when needed

==> Item 25: Design method signatures carefully

==> Item 27: Return zero-length arrays, not nulls

==> Item 28: Write doc comments for all exposed API elements

==> Item 38: Adhere to generally accepted naming conventions

==> Item 47: Don't ignore exceptions


-Sean




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>