|
| Re: EcoreUtil.copy and String attributes [message #689446 is a reply to message #689379] |
Mon, 27 June 2011 16:22   |
 Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Pete,<br>
<br>
You've ignored this Javadoc for EObject<br>
<blockquote> * The framework also assumes that implementations will
not specialize {@link #equals(Object)} (nor {@link #hashCode()})<br>
* so that "<code>==</code>" can be always used for
equality testing;<br>
* {@link org.eclipse.emf.ecore.util.EcoreUtil#equals(EObject,
EObject) EcoreUtil.equals} should be used for doing structural
equality testing.<br>
</blockquote>
More comments below.<br>
<br>
<br>
On 27/06/2011 7:35 AM, Pete Ellis wrote:
<blockquote cite="mid:iua3t6$nt6$1@news.eclipse.org" type="cite">Hello
all,
<br>
<br>
A quick one: EcoreUtil.copy wants to invoke hashCode() on items
that it is copying. This seems to exception out, however, in the
case where a String attribute of the object to copy is "null".
The auto generated code in my xyzImpl class looks like:
<br>
<br>
public int hashCode() {
<br>
return getValue().hashCode();
<br>
}
<br>
<br>
where getValue() returns the String attribute "value".
<br>
</blockquote>
You've specialized equals as well? And you've carefully defined
equals and hashCode in Xyz interface? Nothing is allowed to extend
Xyz? You've ensured that such extensions won't end up producing an
asymmetric result for equality testing?<br>
<br>
As an example of the lengths you must go through to define these
properly, look at java.util.List's definitions of equals and
hashCode; note they even go so far as specifying the exact algorithm
that must be used for computing the hash code. Consider how it's
different from java.util.Set and consider how java.util.Collection
doesn't define it at all (so a Set can never be equal to a List nor
vice versa).<br>
<blockquote cite="mid:iua3t6$nt6$1@news.eclipse.org" type="cite">
<br>
Any way around this? Should the code that is automatically
generated for the hashCode() method concern itself with the
possibility of null values?</blockquote>
We don't automatically generate code for hashCode and absolutely
such code must produce a result for all possible cases.<br>
<blockquote cite="mid:iua3t6$nt6$1@news.eclipse.org" type="cite"> Or
should I work on my end to ensure that String attributes (or any
attribute for that matter, it would seem) are never null?
<br>
</blockquote>
Don't do it.<br>
<blockquote cite="mid:iua3t6$nt6$1@news.eclipse.org" type="cite">
<br>
Thanks for any feedback on this,
<br>
<br>
-Pete
<br>
<br>
FYI: Using EMF 2.5 on Eclipse 3.5.1 <br>
</blockquote>
</body>
</html>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: EcoreUtil.copy and String attributes [message #689489 is a reply to message #689446] |
Mon, 27 June 2011 17:44 |
Pete Ellis
Messages: 85
Registered: July 2009 |
Member |
|
|
<HTML><HEAD>
<META content="text/html; charset=ISO-8859-1" http-equiv=Content-Type></HEAD>
<BODY dir=ltr bgColor=#ffffff text=#000000>
<DIV dir=ltr>
<DIV style="FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: 12pt">
<DIV>Good grief; overriding implementations for both hashCode() and equals()
were inserted by another developer on our team; my apologies.</DIV>
<DIV> </DIV>
<DIV>Thanks for the pointer to EcoreUtil.equals() – that should answer the call
for us.</DIV>
<DIV> </DIV>
<DIV>-Pete</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV
style="BORDER-BOTTOM-COLOR: #000000; BORDER-LEFT: #000000 4px solid; BORDER-TOP-COLOR: #000000; PADDING-LEFT: 5px; BORDER-RIGHT-COLOR: #000000; MARGIN-LEFT: 5px">
<DIV
style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: none">
<DIV>"Ed Merks" <Ed.Merks@gmail.com> wrote in message
news:iuaa6h$uto$1@news.eclipse.org...</DIV></DIV></DIV>
<DIV
style="BORDER-BOTTOM-COLOR: #000000; BORDER-LEFT: #000000 4px solid; BORDER-TOP-COLOR: #000000; PADDING-LEFT: 5px; BORDER-RIGHT-COLOR: #000000; MARGIN-LEFT: 5px">
<DIV
style="FONT-STYLE: normal; DISPLAY: inline; FONT-FAMILY: 'Calibri'; COLOR: #000000; FONT-SIZE: small; FONT-WEIGHT: normal; TEXT-DECORATION: none">Pete,<BR><BR>You've
ignored this Javadoc for EObject<BR>
<BLOCKQUOTE>* The framework also assumes that implementations will not
specialize {@link #equals(Object)} (nor {@link #hashCode()})<BR>* so that
"<code>==</code>" can be always used for equality testing;<BR>*
{@link org.eclipse.emf.ecore.util.EcoreUtil#equals(EObject, EObject)
EcoreUtil.equals} should be used for doing structural equality
testing.<BR></BLOCKQUOTE>More comments below.<BR><BR><BR>On 27/06/2011 7:35 AM,
Pete Ellis wrote:
<BLOCKQUOTE cite=mid:iua3t6$nt6$1@news.eclipse.org type="cite">Hello all,
<BR><BR>A quick one: EcoreUtil.copy wants to invoke hashCode() on items
that it is copying. This seems to exception out, however, in the case
where a String attribute of the object to copy is "null". The auto
generated code in my xyzImpl class looks like: <BR><BR>public int hashCode() {
<BR>return getValue().hashCode(); <BR>} <BR><BR>where getValue() returns the
String attribute "value". <BR></BLOCKQUOTE>You've specialized equals as
well? And you've carefully defined equals and hashCode in Xyz
interface? Nothing is allowed to extend Xyz? You've ensured that
such extensions won't end up producing an asymmetric result for equality
testing?<BR><BR>As an example of the lengths you must go through to define these
properly, look at java.util.List's definitions of equals and hashCode; note they
even go so far as specifying the exact algorithm that must be used for computing
the hash code. Consider how it's different from java.util.Set and consider
how java.util.Collection doesn't define it at all (so a Set can never be equal
to a List nor vice versa).<BR>
<BLOCKQUOTE cite=mid:iua3t6$nt6$1@news.eclipse.org type="cite"><BR>Any way
around this? Should the code that is automatically generated for the
hashCode() method concern itself with the possibility of null
values?</BLOCKQUOTE>We don't automatically generate code for hashCode and
absolutely such code must produce a result for all possible cases.<BR>
<BLOCKQUOTE cite=mid:iua3t6$nt6$1@news.eclipse.org type="cite">Or should I
work on my end to ensure that String attributes (or any attribute for that
matter, it would seem) are never null? <BR></BLOCKQUOTE>Don't do it.<BR>
<BLOCKQUOTE cite=mid:iua3t6$nt6$1@news.eclipse.org type="cite"><BR>Thanks for
any feedback on this, <BR><BR>-Pete <BR><BR>FYI: Using EMF 2.5 on
Eclipse 3.5.1 <BR></BLOCKQUOTE></DIV></DIV></DIV></DIV></BODY></HTML>
|
|
|
|
| Re: EObject == Javadoc; was EcoreUtil.copy and String attributes [message #689530 is a reply to message #689509] |
Mon, 27 June 2011 18:50 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ed,<br>
<br>
Comments below.<br>
<br>
On 27/06/2011 11:30 AM, Ed Willink wrote:
<blockquote cite="mid:iuahn3$744$1@news.eclipse.org" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi Ed<br>
<br>
I must be being very stupid, but I don't understand the comment.<br>
<blockquote cite="mid:iuaa6h$uto$1@news.eclipse.org" type="cite">
You've ignored this Javadoc for EObject<br>
<blockquote> * The framework also assumes that implementations
will not specialize {@link #equals(Object)} (nor {@link
#hashCode()})<br>
* so that "<code>==</code>" can be always used
for equality testing;<br>
* {@link org.eclipse.emf.ecore.util.EcoreUtil#equals(EObject,
EObject) EcoreUtil.equals} should be used for doing structural
equality testing.<br>
</blockquote>
</blockquote>
Surely how "==" is used for equality testing is unaffected by
equals(Object) overloads?<br>
</blockquote>
No, the point is that the framework assumes that the implementation
not override equals for hashCode so just as for java.lang.Object
instances a and b, (a == b) == (a == null ? b == null :
a.equals(b)). <br>
<blockquote cite="mid:iuahn3$744$1@news.eclipse.org" type="cite"> <br>
Is there a stronger coherence requirement than Java's a.hashCode()
!= b.hashCode() implies !a.equals(b)?<br>
</blockquote>
No, that's impossible to guarantee for almost any not trivial class.<br>
<blockquote cite="mid:iuahn3$744$1@news.eclipse.org" type="cite"> <br>
I did a quick experiment and put final versions of equals and
hashCode in EObjectImpl; 3 pairs of errors from MDT/OCL.</blockquote>
Yes not everyone follows the advice.<br>
<blockquote cite="mid:iuahn3$744$1@news.eclipse.org" type="cite">
Two in test classes, but one in a private static class in the main
code supporting Tuples that are a kind of dynamic class. The
implementations of equals and hashCode are non-trivial, so
hopefully carefully coded and so complying with the Java
constraint but not the EObject constraint. Should I be raising a
Bugzilla on OCL for violating the EObject Javadoc or on EMF Core
for an inappropriate EObject Javadoc?<br>
</blockquote>
I don't demand (or enforce) that everyone follow the advice. I
just explain what people should do and then let them do whatever
they want at their own risk. Perhaps they have a good reason to
ignore the advice and are willing to live the with consequences...<br>
<blockquote cite="mid:iuahn3$744$1@news.eclipse.org" type="cite"> <br>
Regards<br>
<br>
Ed Willink<br>
</blockquote>
</body>
</html>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Powered by
FUDForum. Page generated in 0.02814 seconds
] 
Search
Help
Register
Login
Home
