[almighty] Equaler considered harmful

[Todd Mancini]

But just who copied whom? :)

https://msdn.microsoft.com/en-us/library/system.icomparable(v=vs.110).aspx

(I'm sure some wiseguy will tell me that both copied from Smalltalk or PL/I
or something similar.)

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
>
> _______________________________________________
> 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/db11201b/attachment.htm>