'Equals' in any-typed code: VERY BIG PROPOSAL

[Vitaly Davidovich]

So regarding terseness/shortness, you could use java.lang.Objects.equal ()
static method;  static import it and you have: equals (car.getColor (),
someColor).  If an <any T> version is added, that seems pretty good to me.

Sent from my phone
On Jan 7, 2015 11:58 PM, "Thomas W" <twhitmore.nz at gmail.com> wrote:

> Hi Vitaly,
>
> Thanks for your interest in this area.
>
> > Why do you need language feature for #2? What's wrong with calling a lib
> > method that wraps this up for you?
>
> Collections are built on 'eq' and 'hashCode'. It's a fundamental basic
> operator on values, and we're now moving to support values. So, change is
> here & we have an opportunity to get it right.
>
> You are correct, a static helper/ or EqualsStrategy can also achieve this
> for collections.
>
> But for the language more widely & application programming in general, an
> 'eq' operator would be a great help. As well as being a very simple & clean
> solution for specializable Collections.
>
> Here's a demonstration of length:
>
>     if (car.getColor() != null && car.getColor().equals( someColor))) {
>     if (ObjectUtils.equals( car.getColor(), someColor)) {
>     if (car.getColor() eq someColor)) {
>
> There is a massive difference in the amount of typing, and in clarity.
>
> > Changing the language is a high barrier to entry
>
> Language changes are necessary to have any kind of syntax for
> specialization, that is not a rabidly horrible bunch of hacks. So I think
> we are over that barrier already.
>
> Millions will cheer & thanks you!
>
> > and personally,  it seems like eq is just shorthand for a generic method
> that can deal with this
> > just as well.
>
> Logically, 'equals' is an _operator_ not a _method_. Now is the time to
> get this right. Alongside specialization, the Java 10 release will be
> marked with fireworks, champagne & celebration.
>
> > one language change I'd appreciate is the elvis operator since you can't
> emulate that via lib.
>
> Really, we can only consider the most concise & conservative set of
> operators -- that will stand on their own, solve the very biggest bugbear,
> and not be subject to "scope creep". Having a clear boundary for features
> is very important.
>
> I like the Elvis operator too -- and case-insensitive equals for strings
> -- but I'm putting forward a bounded proposal, prompted by the need for
> 'equals' in Collections. I want to start with that; it's also the most
> common form in Java application development.
>
>
> Regards,
> Thomas
>