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.
best regards
Stephan