| Really strange bug with label [message #121728] |
Wed, 25 April 2007 08:45  |
Eclipse User |
|
|
|
Hello,
I've got a node with two containers. Each container contains labels,
that we can add with a button. While my second container works perfectly
well (and was done sometimes ago), the first one doesn't display the
label, but instead the default text, or nothing if there is none. Even
if the user enter text when adding it or with the 'properties' view it
doesn't work.
I deleted generated files, regenerated .gmfgen and regenerated Java
files but the problem persists.
Any ideas ? I'm really stuck.
Generated code for label part is here : http://rafb.net/p/uohiCp46.html
Youmm.
|
|
|
|
|
|
|
|
| Re: Really strange bug with label [message #121983 is a reply to message #121944] |
Thu, 26 April 2007 07:06  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Youmm,
You should think about the implications of that statement though. For
something to be structurally one could even argue that the container
should be taken into account and even if it's not, any kind of equality
test would involve visiting an arbitrarily big subtree. This would make
hashCode so expensive you'd likely need to cache the value. Then you'd
get into the issue that any change to anything in the entire structure
will change equality, or even if your hashCode only looked at local
fields, any change in value would change the hashCode so that, in either
case, any map (other than an IdentifyHashMap) holding the value has a
key would be corrupted. This is likely why DOM supports isEqualNode but
doesn't make equals itself be based on structural equality, and yet DOM
is still a Java API.
Youmm P. wrote:
>
>>
>> The framework also assumes that implementations will not specialize
>> |equals(Object)| (nor |hashCode()|) so that "|==|" can be always
>> used for equality testing; |EcoreUtil.equals| should be used for
>> doing structural equality testing.
>>
> Hum. OK thanks, EcoreUtil.equals is what I need.
>
> In my own opinion, == should be used for references testing, and
> equals method for structural testing. Just like a Java API should be.
|
|
|
|
| Re: Really strange bug with label [message #122023 is a reply to message #122010] |
Thu, 26 April 2007 09:52 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------080705070607080903070202
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Youmm,
Often equals is called indirectly. For example, if you add the object to
a HashSet or as the key of a HashMap, then equals will end up being
called. And when two lists containing EObjects are tested for equality,
equals is used to compare them (although EMF's extended list
implementation will use == for EObject containing list and will hence be
*far *more efficient, but will appear to misbehave if .equals is
overridden in the derived EObjectImpl).
Youmm P. wrote:
>
>> something to be structurally one could even argue that the container
>> should be taken into account and even if it's not, any kind of
>> equality test would involve visiting an arbitrarily big subtree. This
>> would make
> That's a good point. In this case equals should not be used at all. So
> if there is this kind of refresh bugs I suppose, upper in the
> hierarchy, equals is called on an EObject and inheritance plays its
> role and call my equals.
>
> Why is equals called instead of '==' ? Or perhaps there is a useful
> definition of Equals in EObject (or in its parents) that is used
> internally. In this case they should used their own equals method
> (like emfEquals) to avoid client classes to reimplement equals, no ?
--------------080705070607080903070202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!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">
Youmm,<br>
<br>
Often equals is called indirectly. For example, if you add the object
to a HashSet or as the key of a HashMap, then equals will end up being
called. And when two lists containing EObjects are tested for
equality, equals is used to compare them (although EMF's extended list
implementation will use == for EObject containing list and will hence
be <b>far </b>more efficient, but will appear to misbehave if .equals
is overridden in the derived EObjectImpl).<br>
<br>
<br>
Youmm P. wrote:
<blockquote cite="midf0q83a$33g$1@build.eclipse.org" type="cite"><br>
<blockquote type="cite">something to be structurally one could even
argue that the container should be taken into account and even if it's
not, any kind of equality test would involve visiting an arbitrarily
big subtree. This would make </blockquote>
That's a good point. In this case equals should not be used at all. So
if there is this kind of refresh bugs I suppose, upper in the
hierarchy, equals is called on an EObject and inheritance plays its
role and call my equals.
<br>
<br>
Why is equals called instead of '==' ? Or perhaps there is a useful
definition of Equals in EObject (or in its parents) that is used
internally. In this case they should used their own equals method (like
emfEquals) to avoid client classes to reimplement equals, no ?
<br>
</blockquote>
<br>
</body>
</html>
--------------080705070607080903070202--
|
|
|
Powered by
FUDForum. Page generated in 0.17658 seconds
Home