[almighty] Equaler considered harmful

[Konrad Kleine]

Hi Thomas,

thanks for not pointing in my direction :)

I can't wait to see a PR for this.

Regards,
Konrad

On Thu, Sep 22, 2016 at 3:32 PM, Thomas Mäder <tmader at redhat.com> wrote:

> Hi folks,
>
> some time back, we have introduced the "Equaler" interface. I believe
> we're going down the wrong path with this: Java got this wrong initially
> and we still suffer the consequences. Equaler looks like this:
>
> type Equaler interface {
>     Equal(Equaler) bool
> }
>
> There are a couple of drawbacks to this approach:
>
>    1. There can only be a single implementation of Equals for all time.
>    But this too restrictive: for example, I might want to include the version
>    field in a struct in the comparison for some cases, in other cases I simply
>    don't care. Generally, there can be many equivalence relationships for a
>    given set of objects. For all we know, we might consider two objects equal
>    if they have the same color.
>    2. You can't compose equality with this implementation
>    In Java, this has given rise to classes like "EqualsBuilder" that
>    allowed to do exactly that.
>    3. We can't implement equality based on interfaces
>    We'd have to reimplement equality for every struct (which is the first
>    parameter).
>    4. You always have to check for null before calling Equals()
>
> So I propose to rewrite the interface to :
>
> Equality {
>
>     Equals(left interface{}, right interface{}) bool
>
> }
>
> I think it would make sense that I prepare a PR to illustrate my approach
> porting the current implementations in the "models" packe. A POC shouldn't
> take too long.
>
> thoughts?
>
> /Thomas
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160922/5273fd6a/attachment.htm>