Fwd: Optional syntax for implements and extends

[Brian Goetz]

Received on the amber-spec-comments list; replying here.

>
> Subject:     Optional syntax for implements and extends
> Date:     Thu, 31 Jan 2019 19:25:44 -0500
> From:     Francois Green <francois.green at gmail.com>
> To:     amber-spec-comments at openjdk.java.net
>
>
> How badly would Java break if one could optionally replace extends or
> implements with a colon?
>
> interface I {}
> static abstract class C { }
> static class A extends C implements I { }
> static class B extends C implements I { }
> //vs
> interface I;
> static abstract class C { }
> static class A : C, I { }
> static class B : C, I { }
>
> From the first version above, one can easily infer that C is a class and I
> is an interface. But what does knowing this help me to achieve? For those
> us who only consume libraries, it would be nice to not have to type all
> that if we didn't need or care to. Plus think of the reduction in carpal
> tunnel cases that having this option might bring about.

The short answer is: there is no appetite for such tinkering.

If we were designing a language from scratch, I would put this in the 
category of "credible idea."  That is, it's not a downright _bad_ idea 
(though, see below).  But, "what would we do with a clean paper" and 
"should we change Everybody's Java now" are completely different questions.

Even though it's not a downright bad idea, it's not great either. That's 
because _reading code is more important than writing code_, and this 
idea is purely about saving a few keystrokes when writing code.  And it 
doesn't offer the ability to do anything new; it's merely a syntactic 
shortcut. Wrong end of the lever.

But worse, suppose we allowed this.  And suppose it was popular, as you 
expect, and lots of people were motivated to go out and change their 
perfectly-fine code to follow this fashion choice. Where does that leave 
the world of Java code, and what are the costs and benefits?  For the 
next (forever), we'll be in a world where some of the code is one way, 
and some is the other way. Readers will have to deal with both; books 
and classes will have to cover both, because both will be commonly 
encountered in the wild.  There will be arguments about which is 
better.  There will be questions on stack overflow about "which should I 
use", with "primarily opinion-based" answers that don't really help.  
There will be style guides and style checkers, and much effort will be 
spent on "enforcing" one or the other.

For absolutely no value.  It doesn't make our code more readable, or 
less error-prone.  It doesn't make it more functional, or expressive. It 
just saves a few keystrokes when typing.

So you ask: "what would break?"  And the answer is: more cognitive load 
for every Java developer, and more things to learn for every student.  
That's a lot.

If we're going to ask people to migrate their code to use a new 
mechanism, that new mechanism had better offer some payback, such as 
improved readability, improved expressiveness, improved safety, or 
improved performance.  We're going to save our effort -- and our budget 
for asking people to absorb new concepts -- for that.