RE: [httpclient] API design, Cookie.getExpiryDate, Cookie.setExpi ryDate

["Waldhoff, Rodney" <rw...@us.britannica.com>]

Yeah, lots of good ideas in there, but performance and memory use should be
a priority as well.  (Funny, I'm usually on the other side of this
argument.)

dIon makes a good point with the Collections example (list.get(1).setFoo(x);
changes the value in list); and frankly I think it's fairly unreasonable
clients to treat the Cookie.getDate() value as mutable (or, to put it
another way, I think it's perfectly reasonable to tell them to treat it as
immutable).  It's not like a desire or reason to change that value leaps out
at you.

I guess I don't mind making the defensive copy as much as I mind committing
ourselves to making the defensive copy if it turns out to be a performance
or footprint issue (and it seems to me that it likely will).  If we make a
defensive copy, we should still document that the object should be
considered immutable (which begs the question, why bother to make the copy?)

-----Original Message-----
From: Sean C. Sullivan [mailto:sean@seansullivan.com]
Sent: Thursday, February 07, 2002 10:33 AM
To: Jakarta Commons Developers List
Subject: Re: [httpclient] API design, Cookie.getExpiryDate,
Cookie.setExpiryDate



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>