11:17 p.m.
On Tue, Oct 18, 2011 at 12:06 PM, Stuart Douglas <sdouglas(a)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(a)redhat.com>
>> To: Mark Struberg <struberg(a)yahoo.de>
>> Cc: cdi-dev(a)lists.jboss.org; Stuart Douglas <sdouglas(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
--
*Rick Hightower*
(415) 968-9037
Profile <http://www.google.com/profiles/RichardHightower>