PROPOSAL: Auto-assignment Parameters

[Stephen Colebourne]

Mark Mahieu wrote:
>     class Proposal {
>         private final String name;
>         private final String author;
>         private boolean suitableForCoin;
>         private Integer score;
>         public Proposal(String this.name,
>                         String this.author,
>                         boolean this.suitableForCoin,
>                         int this.score) {
>             if (name.equals(“Auto-assignment Parameters”)) {
>                suitableForCoin = true; // final so compile-time error
>             }
>         }
>     }

Very cool. I like it.

> DESIGN ALTERNATIVES:
> 
> The following variations have been explored and are worth mentioning:
> 
> * Allow auto-assignment parameters on all non-abstract methods.
>     This may be especially useful on the extremely common 'setter' methods
> in 'value object' classes.

I think its right to leave this out for now, pending more investigation 
into a bigger properties solution.

> * Remove the requirement for (or even disallow) the type to be specified on
> auto-assignment parameters.
>     Experimentation with this idea suggests that it may work quite well for
> constructors, further emphasising the difference in intent and semantics
> from those of normal parameters. However, it may not work so well in
> combination with auto-assignment parameters on all non-abstract methods, and
> requires a change to the order in which javac compiles classes (can still
> pass jtreg tests).

The inference can be added later. It doesn't feel quite right.

> * Allow an alternative name to be specified.
>     This adds additional complexity to support a fractional percentage of
> cases, which could continue to use the existing coding pattern.

Not worth it.

Stephen