<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 19/10/2011, at 8:17 AM, Rick Hightower wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Tue, Oct 18, 2011 at 12:06 PM, Stuart Douglas <span dir="ltr"><<a href="mailto:sdouglas@redhat.com">sdouglas@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
If the 'other' instance is also a proxy, then both proxies will by definition be equal, as they will always resolve to the same underlying bean (as they are both being accessed by the same thread, that will have the same contexts active).<br>
</blockquote><div><br></div><div>They are not comparing two normal objects they are comparing an object and an instance. We are defining how proxies equals work, which is to get the underlying real object and compare it to the incoming real object or the real object from the proxy.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Anything we specify here is going to break the transitive behaviour of equals, consider we have a proxy A and normal class instantiated with new B.<br>
<br>
The normal class B has absolutely no knowledge of proxies, so will always compare the proxy instances fields directly, if we have the proxy forwarding the equals call to the underlying bean then you may end up with a situation where A.equals(B) is true, but B.equals(A) is false.<br>
</blockquote><div><br></div><div>Good point. So to not break this contract, we would only say that proxies can compare against other proxies. If they want to compare a proxy to a normal object they would have to use the utility methods I described earlier to unpack it. We could add an equals static method to this utility as well.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
HashCode has similar problems, if the proxy forwards it to the underlying bean, then the hash code will change as the underlying bean changes.<br></blockquote><div><br></div><div>But not within a Request scope or within a Session scope. I think this is ok actually. Much more so than the equals case. At least in the way people will actually use this in a web app. :)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I think we should specify that non-portable behaviour results, and tell people not to put proxies into a HashMap.<br>
<font color="#888888"><br>
Stuart<br></font></blockquote><div><br></div><div>Summary:</div><div><br></div><div><br></div></div></blockquote><blockquote type="cite"><div class="gmail_quote"><div>equals should only work with other client proxies, it should unpack and call equals on unpacked.</div></div></blockquote><div><br></div><div>This also breaks the contract for equals. Also this behaviour is useless, as two client proxies will always resolve to the same underlying object. </div><br><blockquote type="cite"><div class="gmail_quote"><div><br></div><div>
hashCode should just work, it should unpack and call hashCode on underlying object (contextual instance in spec speak right?)</div><div><br></div><div><br></div></div></blockquote><div><br></div><div>No, a mutable hashCode is much worse than a unspecified one IMHO. The main point of hashCode is to allow objects to work in HashMaps, and this will result in completely broken behaviour. </div><div><br></div><div>The way we deal with this in Weld is to use the client proxies class hashCode for hashCode (i.e. MyObject$$Proxy.class.hashCode() ), and consider proxies equal if they are both proxies for the same Bean.</div><div><br></div><div>Stuart</div><br><blockquote type="cite"><div class="gmail_quote"><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888">
</font><div><div></div><div class="h5"><br>
<br>
On 19/10/2011, at 4:17 AM, Mark Struberg wrote:<br>
<br>
> Hi folks!<br>
><br>
> There is a problem still in the chain which is a bit more trickier. It's about equals() on contextual references.<br>
><br>
> If the 'other' instance which gets compared with is a proxy as well, then we would first need to 'unpack' it and pass the underlying contextual instance into the comparison implementation. Otherwise accessing private fields from the 'other' will actually only hit the proxy, and not the 'real' target.<br>
><br>
> But otherwise it should work fine.<br>
><br>
><br>
> Wdyt?<br>
><br>
> 1.) Should we specify this?<br>
><br>
> 2.) What is the expected behaviour?<br>
><br>
> 3.) Do we like to specify equals() for beans at all?<br>
> 4.) Is there some established behaviour in other frameworks which heavily uses proxies?<br>
> 5.) Should we at least specify that 'non portable behaviour results'?<br>
><br>
><br>
> LieGrue,<br>
> strub<br>
><br>
><br>
><br>
> ----- Original Message -----<br>
>> From: Pete Muir <<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>><br>
>> To: Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>><br>
>> Cc: <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>; Stuart Douglas <<a href="mailto:sdouglas@redhat.com">sdouglas@redhat.com</a>><br>
>> Sent: Monday, March 14, 2011 12:52 PM<br>
>> Subject: Re: [cdi-dev] calling 'equals' on a proxy?<br>
>><br>
>> Stuart, you had this one worked out right? I believe the spec says the behaviour<br>
>> is unspecified.<br>
>><br>
>> On 7 Mar 2011, at 15:52, Mark Struberg wrote:<br>
>><br>
>>> Hi Pete, others!<br>
>>><br>
>>> Do you remember our discussion about what should happen if equals() gets<br>
>> called on a proxy?<br>
>>><br>
>>> Should it route to the equals method of the currently proxied instance?<br>
>>><br>
>>> LieGrue,<br>
>>> strub<br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> cdi-dev mailing list<br>
>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><b>Rick Hightower</b><br>(415) 968-9037 <br><a href="http://www.google.com/profiles/RichardHightower" target="_blank">Profile</a> <br><br>
</blockquote></div><br></body></html>