On Jun 17, 2008, at 3:55 PM, Stephan Koops wrote:
> Hi Marc,
>>> But IMO this class should get the methods hashCode() and equals(.).
>>> The logic requires, that (nc = aNewCookie, c = aCookie) if (nc1 ==
>>> c && c == nc2) than MUST nc1 == nc2
>>> But the equality of nc and c could only be checked about the
>>> values of the attributes of Cookie. From this follows, that a
>>> Cookie must not be equal to a NewCookie. So there must taken care.
>>> One possibility is to add a second equals method with an addition
>>> parameter which says, if a Cookie could be equal to a NewCookie,
>>> where the default is false.
>> Agree that a NewCookie should never be equal to a Cookie.
>>
>> Perhaps we should add a method to NewCookie that will get a Cookie
>> that could be used for comparison. E.g.:
>>
>> Cookie c = ...
>> NewCookie nc = new NewCookie(c);
>> assertEquals(nc.getCookie(), c);
>>
>> Not sure how much use this would really be though. Anyone have a
>> good use case for comparing a Cookie to a NewCookie ?
> I though to something like:
>
> public class Cookie {
> ...
> public boolean equals(Object otherCookie, boolean
> cookieMaybeEqualToNewCookie) { // or whatever name for the boolean
> ...
> }
>
> public boolean equals(Object otherObject) {
> return this.equals(otherObject, false);
> }
> }
>
> Another possibility: change the hierarchie to
> AbstractCookie (with the attributes name, value, version, path and
> domain as now in Cookie)
> +-- Cookie
> +-- NewCookie
>
> AbstractCookie would implement equals(AbstractCookie) with default
> visibility, and define equals(Object) and equals(Object, boolean) as
> abstract method, which are implemented as above. This methods must
> check, that only valid object are passed to
> AbstractCookie.equals(AbstractCookie), according to the boolean value.
>
> IMO the second design is better. Perhaps it is useful to define
> AbstractCookie as public, so it is possible - if someone needs it -
> to put Cookies and NewCookies into one Collection.
>
I understood what you were suggesting but before we start picking
among the possibilities I'd first like to see if there are any real
use-cases that require this kind of functionality. IMO, both Cookie
and NewCookie are both quite transient artifacts from a service POV:
- you get a Cookie in a request, extract some information from it and
discard it
- you create a NewCookie, add it to a response and discard it
What I'd like to see is a reasonable use case that requires comparing
a Cookie and a NewCookie instance for equality considering only the
attributes they have in common.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.