On Jun 17, 2008, at 2:59 PM, Stephan Koops wrote:
>
> 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 ?
> Another possibility is to say, that this would not happen and ignore
> it, but that's not good IMO. Marc, if I should implement it, let me
> know.
>
Thanks for the offer but no need - NetBeans will generate a nice
implementation of equals and hashcode that will likely require very
little tweaking.
Marc.
>
> Marc Hadley schrieb:
>> https://jsr311.dev.java.net/issues/show_bug.cgi?id=39:
>>
>> "While they share a number of attributes, Cookie and NewCookie
>> serve different purposes. It might be cleaner if NewCookie
>> contained a Cookie rather than inheriting from it."
>>
>> From Stephan:
>>
>> "Issue 39: if NewCookie should not subclass Cookie for design
>> reasons, then NewCookie could contain the same 5 attributes and
>> it's getter. I see no advantage that NewCookie has a Cookie as
>> attribute. Another possibility is a common subclass with the
>> attributes of Cookie, or a common interface. The first reduces the
>> lines of code, and both allows to handle a NewCookie and a Cookie
>> together, if someone needs it. For equals(.) a NewCookie must never
>> be equal to a Cookie, also if all values are the same, because noth
>> classes have a little bit different semantics. Perhaps we could add
>> an equal method If there is a common abstract class, their could be
>> a method AbstractCookie.equals(Cookie, boolean), which boolean
>> parameter allows to indicate, if a Cookie could be equal to a
>> NewCookie or not."
>>
>> I'm tempted to close this one with no action (i.e. leave it as
>> NewCookie extends Cookie) - anyone have a strong opinion to the
>> contrary ?
>>
>> Marc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.