opened
fabriciofx
username_0
I see a lot of this (bellow) code repeat over and over:
```
@Override
public boolean equals(final Object other) {
    return new Unchecked<>(
        new Or(
            () -> other == this,
            new And(
                () -> other != null,
                () -> Collection.class.isAssignableFrom(other.getClass()),
                () -> {
                    final Collection<?> compared = (Collection<?>) other;
                    return this.size() == compared.size();
                },
                () -> {
                    final Collection<?> compared = (Collection<?>) other;
                    final Iterator<?> iterator = compared.iterator();
                    return new Unchecked<>(
                        new And(
                            (T input) -> input.equals(iterator.next()),
                            this
                        )
                    ).value();
                }
            )
        )
    ).value();
}
```
and I think is possible encapsulate it in one class to be reused. WDYT?
A new kind of Equals?
issue
created
0crat
username_1
@paulodamaso[/z](https://www.username_1.com/u/paulodamaso) please, pay attention to this issue
comment
created
fabriciofx
username_0
@username_2 WDYT?
comment
created
victornoel
username_2
@username_0 so something similar to `HashCode` but for `Equals`? What I am worried about is that this code should not be duplicated so much normally. Each of the classes that implements equals should have their own, internal state related, implement IMHO.

Could you make a list of the classes that would use this `Equals` and see in practice what it would entails?
comment
created
victornoel
username_2
@username_0 following some discussion with @andreoss (see https://github.com/yegor256/cactoos/pull/1458#discussion_r487550572), I now realise that maybe something we could do is provide, for each of the interfaces supported by cactoos (and for which it makes sense), a class `Equals implements Scalar<Boolean>` and a class `HashCode implements Scalar<Integer>` that the implementations of those interfaces could reuse when needed.

@skapral I remember you had some opinion about equals and hashCode, don't hesitate to chime in :)

There is also a debate in #1156 where @fanifieiev (don't hesitate to chime in too :) made an interesting comment (on top of all the others there): https://github.com/yegor256/cactoos/issues/1156#issuecomment-553619095

There is also #920 with some similar concerns for the proc/func/scalar packages but I don't think those are classes that would really benefit of having equals IMHO because they don't really have a comparable state exposed through their behaviour.
comment