Defender methods and compatibility

[Jim Mayer]

>
>
> This collaborative approach is an experiment on our part towards greater
> community engagement.  If the community cannot meet us halfway by showing
> some
> restraint (for example, by recognizing when it has ratholed and backing
> off),
> it will be a failed experiment, for which we will all be losers.
>
>
Brian,

When you called for a close on the mutable local variables discussion most
people stopped (and what continued was mostly sparked by folks catching up
with list traffic).  I, for one, would have preferred a different outcome.
 On the other hand, I agreed with your analysis that:

(1) The feature was controversial.
(2) The choice being made was conservative, as the current restrictions
could be relaxed in the future without breaking backwards compatibility.

I also accepted the premise that you set out at the beginning of that
discussion when you said:

> In order to justify the complexity that these new features would generate,
there needs to be a compelling use case.

So, what is the compelling use case for adding a special disambiguation
rule?

I haven't seen one.  In fact, the closest I've seen to a concrete use case
was Neal's Google "third generation collections API" horror story.

It also seems to me that the rule could be added later without breaking
backwards compatibility.

Anyway, that's my two cents.

-- Jim

P.S., In the spirit of "chickens" everywhere, here's a concrete proposal:

(1) Drop the "same initializer" disambiguation rule.
(2) Change the syntax to follow the short hand for method references (E.g.,
 "extension void m() default #SomeClass.method;")

By making the syntax be compatible with the short hand for method references
we open up the possibility of using lambda expressions to specify the
default.  This is cool on several fronts:

(a) It looks like a constant definition (one could even play with swapping
'default' for '=').  They're already legal in interfaces.
(b) It could be extended in the future to actually BE a constant definition
(E.g., "#{thing->...}", "SomeFactory.THE_DEFAULT" or even
"SomeFactory.theDefaultOperation()").  This would provide for inline
specification if it proved useful while remaining true to the historical
"feel" of Java interfaces.
(c) It could be left as a restricted form and the special disambiguation
rule could be reintroduced.

Just a thought :-)