[almighty] Equaler considered harmful

[Andrew Lee Rubinger]

Also, a bit curious:

Equality {
    Equals(left interface{}, right interface{}) bool
}

What does the implementation of this look like?  Its usage?  Because now to
achieve your point 4) we've moved the responsibility of determining
equality from the object in question to some external equality-checker.
How does the equality-checker know about the various types it has to
support?

S,
ALR

On Thu, Sep 22, 2016 at 11:30 AM, Andrew Lee Rubinger <alr at redhat.com>
wrote:

> Java may have made an odd design design by putting "boolean
> equals(Object)" in the root Object class as a mechanism to test equality by
> value, but there's also:
>
>   https://docs.oracle.com/javase/8/docs/api/java/lang/Comparable.html
>
> This approach handles not just equals but also greater/less than
> comparisons for types that have ordered values.  You could retrofit it to
> return an enum type instead of an int for better clarity.
>
> Something to consider :)
>
> S,
> ALR
>
> On Thu, Sep 22, 2016 at 10:19 AM, Konrad Kleine <kkleine at redhat.com>
> wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>>
>
>
> --
> Red Hat Developer Programs Architecture
> @ALRubinger
>



-- 
Red Hat Developer Programs Architecture
@ALRubinger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20160922/b5cadb77/attachment.htm>