<!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 text="#000000" bgcolor="#ffffff">
On 23/06/2011 10:19, Wolfgang Laun wrote:
<blockquote
cite="mid:BANLkTinRMFAPPvM3zyK=V0M=Q9rMgSd2Cg@mail.gmail.com"
type="cite">Well, you are saying that if you are using references
to fact objects in combination with constraints comparing such a
reference to some other object any (overridden) hashCode method <i><b>must
not refer to mutable fields</b></i> of that object.<br>
</blockquote>
hashCode method <i><b>must not refer to mutable fields</b></i> of
that object.<br>
That's not a good idea really. Hashcode's should refer to fields
that you constrain on, as a general good rule. and those fields are
normally mutable.<br>
<br>
I don't really know what more to say than...<br>
Nested accessors are "black box" if you modify a nested accessor you
must notify the root object(s) that are inserted into the engine.<br>
<br>
If you want to write up some paragraphs talking people through how
hashcode's and hashmap's work. Specifiically if you change the
hashcode of an object that is in map you won't be able to find it in
the map any more - which is what is happening to you. Notification
effectively takes the root object out and put's it back in again, so
it lives in the correct index.<br>
<br>
This is why other engines don't support Objects as fields, you can
only use values - strings, numbers etc. For them it's worse though,
they have to use techniques like shadow facts otherwise they get
memory corruption - but shadow facts only work on direct values, and
cannot shadow objects and nested fields. If you tried to do this
stuff in other engines they would just get corrupted. It's only
because we do a tree-graph based rete network for assymetrical
retract that we can allow you to do this without corruption, but you
must still notify the engine.<br>
<br>
Mark<br>
<blockquote
cite="mid:BANLkTinRMFAPPvM3zyK=V0M=Q9rMgSd2Cg@mail.gmail.com"
type="cite">
<br>
Certainly: this restriction should not hurt - I'm inclined to
regard mutable hashCode methods as "suspicious" anyway.<br>
<br>
But, nevertheless, it deserves a short paragraph in the "Expert"
manual, don't you think so?<br>
<br>
Cheers<br>
Wolfgang<br>
<br>
<br>
<br>
<div class="gmail_quote">On 23 June 2011 10:50, Mark Proctor <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:mproctor@codehaus.org">mproctor@codehaus.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left:
1ex;">
<div text="#000000" bgcolor="#ffffff">
<div class="im"> On 23/06/2011 09:32, Wolfgang Laun wrote:
<blockquote type="cite">If I have <br>
class Type {<br>
int field;<br>
setField( int f ){ field = f; }<br>
}<br>
<br>
and do<br>
<br>
modify( $type ){ setField( 42 ) }<br>
<br>
where is there a "nested accessor"?<br>
</blockquote>
</div>
<div class="im"> $one: One()<br>
$two: Two( $x: one == $one )<br>
<br>
</div>
If you change a field on object "one". that field is a
nested accessor to Two.<br>
one.field1 = "x"<br>
is the same as doing<br>
two.one.field1 = "x"<br>
<br>
so to "two" changing the field of 1 is a nested accessor.<br>
<br>
Think about how indexing works.<br>
left == right<br>
<br>
when two objects are == each other indexing creates a bucket
for the left and a bucket for the right. If you change the
hashcode of the one on the right, how will it find the
bucket on the left?<br>
<font color="#888888"> <br>
Mark</font>
<div>
<div class="h5"><br>
<br>
<blockquote type="cite"><br>
-W<br>
<br>
<div class="gmail_quote">On 23 June 2011 10:24, Mark
Proctor <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:mproctor@codehaus.org"
target="_blank">mproctor@codehaus.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left:
1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt
0.8ex; padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff">
<div> On 23/06/2011 07:03, Wolfgang Laun wrote:
<blockquote type="cite">Eeek!<br>
<br>
Assume this: A is a field of B is a field of
C is a field of D is a... <br>
<br>
Object references remain the same, in all
objects; I simply modify A, and<br>
"when you change [A] you are also changing
[B], so I must notify the<br>
engine for [B]" but that's a field of C...
D... E... and so on, until<br>
'I' for infinity?!<br>
<br>
<u><b><i>It's just a change in some fact
object's hashCode that causes this
problem.</i></b></u><br>
</blockquote>
</div>
If you don't want any indexing in your rule
engine. If you want indexing, you have to notify
the engine. Changes to nested accessors have
always been invisible to the engine. If a nested
access changes, you must notify the engine of
the root fact.<br>
<font color="#888888"> <br>
Mark</font>
<div>
<div><br>
<blockquote type="cite"> <br>
-W<br>
<br>
<br>
<br>
On 22 June 2011 22:37, Mark Proctor <<a
moz-do-not-send="true"
href="mailto:mproctor@codehaus.org"
target="_blank">mproctor@codehaus.org</a>>
wrote:<br>
> As One is a field of Two. When you
change One you are also changing Two, so<br>
> you most notify the engine for Two
too.<br>
><br>
> MArk<br>
> On 22/06/2011 14:37, Wolfgang Laun
wrote:<br>
><br>
> To avoid misunderstandings: yes,
equals() is written according to hashCode,<br>
> i.e., according to the usual Java
conventions.<br>
><br>
> If<br>
><br>
> - an object of class Two contains
a member of class One, and<br>
> - one object Two and one object
One are facts, and<br>
> - a rule modifies One, changing
its hashCode<br>
><br>
> then<br>
><br>
> another rule containing the
patterns<br>
> $one: One()<br>
> $two: Two( $x: one == $one )<br>
><br>
> does NOT fire (any more).<br>
><br>
> If you use the constraint<br>
> one == $one || != $one<br>
> the rule will fire, and you can
observe that hashCode results for $one and<br>
> $x are the same and that $one.equals(
$x ) returns true.<br>
><br>
> Reproduced using 5.1.1 and 5.2.x<br>
><br>
> -W<br>
><br>
><br>
><br>
><br>
>
_______________________________________________<br>
> rules-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org"
target="_blank">rules-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
><br>
><br>
>
_______________________________________________<br>
> rules-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org"
target="_blank">rules-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
><br>
><br>
<br>
<pre><fieldset></fieldset>
_______________________________________________
rules-dev mailing list
<a moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org"
target="_blank">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br>
</blockquote>
</div>
<br>
<pre><fieldset></fieldset>
_______________________________________________
rules-dev mailing list
<a moz-do-not-send="true" href="mailto:rules-dev@lists.jboss.org" target="_blank">rules-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
rules-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/rules-dev</a><br>
<br>
</blockquote>
</div>
<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rules-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>