My comments are below...
From: "dIon Gillard" <[EMAIL PROTECTED]> > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
