[cdi-dev] calling 'equals' on a proxy?

[Rick Hightower]

On Tue, Oct 18, 2011 at 12:06 PM, Stuart Douglas <sdouglas at redhat.com>wrote:

>
> 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).
>

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.


>
> 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.
>
> 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.
>

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.



>
> HashCode has similar problems, if the proxy forwards it to the underlying
> bean, then the hash code will change as the underlying bean changes.
>

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. :)


>
> I think we should specify that non-portable behaviour results, and tell
> people not to put proxies into a HashMap.
>
> Stuart
>

Summary:


equals should only work with other client proxies, it should unpack and call
equals on unpacked.

hashCode should just work, it should unpack and call hashCode on underlying
object (contextual instance in spec speak right?)






>
>
> On 19/10/2011, at 4:17 AM, Mark Struberg wrote:
>
> > Hi folks!
> >
> > There is a problem still in the chain which is a bit more trickier. It's
> about equals() on contextual references.
> >
> > 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.
> >
> > But otherwise it should work fine.
> >
> >
> > Wdyt?
> >
> > 1.) Should we specify this?
> >
> > 2.) What is the expected behaviour?
> >
> > 3.) Do we like to specify equals() for beans at all?
> > 4.) Is there some established behaviour in other frameworks which heavily
> uses proxies?
> > 5.) Should we at least specify that 'non portable behaviour results'?
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> >> From: Pete Muir <pmuir at redhat.com>
> >> To: Mark Struberg <struberg at yahoo.de>
> >> Cc: cdi-dev at lists.jboss.org; Stuart Douglas <sdouglas at redhat.com>
> >> Sent: Monday, March 14, 2011 12:52 PM
> >> Subject: Re: [cdi-dev] calling 'equals' on a proxy?
> >>
> >> Stuart, you had this one worked out right? I believe the spec says the
> behaviour
> >> is unspecified.
> >>
> >> On 7 Mar 2011, at 15:52, Mark Struberg wrote:
> >>
> >>>   Hi Pete, others!
> >>>
> >>>   Do you remember our discussion about what should happen if equals()
> gets
> >> called on a proxy?
> >>>
> >>>   Should it route to the equals method of the currently proxied
> instance?
> >>>
> >>>   LieGrue,
> >>>   strub
> >>>
> >>>
> >>>
> >>>   _______________________________________________
> >>>   cdi-dev mailing list
> >>>   cdi-dev at lists.jboss.org
> >>>   https://lists.jboss.org/mailman/listinfo/cdi-dev
> >>
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>



-- 
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20111018/cfd513cd/attachment.html