On Sep 20, 2010, at 5:26 PM, James Carman wrote:
> On Mon, Sep 20, 2010 at 6:16 PM, Matt Benson <gudnabr...@gmail.com> wrote:
>> Hi all,
>> By default, [proxy]'s provided ProxyFactory implementations all force their
>> generated proxies to implement hashCode via System.identityHashCode() and
>> equals via reference equality. I will leave it to the original author to
>> explain the reasons behind this design decision if he chooses, but I would
>> propose that it would not be out of order to provide a means of allowing a
>> user to implement these methods as any other. If anyone has any opinions to
>> contribute on the matter, please make them known.
>>
>
> As the original author, I do not recall the exact reasoning behind
> this decision at this time. However, I would assume that it has
> something to do with the fact that you may have two different proxies
> with the same "target" object. One of these proxies could have
> interceptors on it (for security, logging, whatever) and the other
> might not. If you let the "target" respond to equals/hashCode, then
> these two proxies would be considered equal, when they clearly should
> not.
>
> I agree that it would be nice to allow the user to override this
> behavior, but I think the general case should be to just use Object's
> implementation of these two methods. I don't want to muddy up
> ProxyFactory's API to do this, though. I'd rather figure out some
> other way to do this. Perhaps we could make every proxy object
> implement some interface (ProxyObject perhaps). That interface could
> have a "setter" on it to allow the user to override the "thing" that
> implements the equals/hashCode methods:
>
> public interface Equalizer<T> {
> public boolean equals(T source, T target);
> public int hashCode(T source);
> }
>
This would seem quite complicated to execute, would it not?
-Matt
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
