Notes on implementing concise calls to constructors with type parameters
Joseph D. Darcy
Joe.Darcy at Sun.COM
Fri May 15 08:38:40 PDT 2009
Especially given the tricky nature of the type system, being able to
play with Maurizio's prototype implementation of the diamond operator
will be extremely helpful and informative. I think Maurizio's approach
provides a favorable migration path and is worth further exploration.
We generally don't want large changes to inference in the compiler or
language in JDK 7 and the small size of Maurizio's patch is encouraging
on that front too.
Neal Gafter wrote:
> On Thu, May 14, 2009 at 4:28 AM, Maurizio Cimadamore <
> Maurizio.Cimadamore at sun.com> wrote:
>> Yes, assuming the "diamond" construct is only to be used on the
>>> right-hand-side of an assignment. But I think it's wrong to make language
>>> constructs non-orthogonal.
>> It seems to me that the "diamond" construct has always had this
>> restricted-ness right from the beginning. See the original draft:
> Noted. That's why I got involved - to get this corrected by designing the
> construct to be orthogonal to assignment. Your approach isn't an
> implementation of this specification - not even close.
> Btw - allowing inference in method invocation context is rather complex - a
>> slight variation of your example fails to compile with both approaches;
>> given the following method declaration:*
> Saying it fails and saying it is complex are two different things. Yes, it
> fails just as it would using static factories, and for exactly the same
> reason. It's because the specification is so *simple* by relying on the
> existing inference algorithm. I'm not suggesting that change until and
> unless it changes for type inference on ordinary method invocations as
> well. Another advantage of my proposed approach is that "fixing" type
> inference for other contexts, as I believe we are likely to do later, would
> automatically fix the diamond operator for those contexts as well without
> any additional specification effort.
>> The bottom-line is: if we just consider inference in assignment context
>> (and I think we should - at least if we want to keep this change 'small'
>> ;-) ), there's no substantial difference between my proposal and yours.
> Inferring type arguments based on the type of value parameters *is *a
> substantial difference. Keeping the spec small is an admirable goal (it
> isn't clear that your approach would result in a smaller spec), but it
> shouldn't be done at the cost of internal language consistency.
> Given that neither approach has even a draft specification, perhaps they
> should be considered out of scope for project coin.
More information about the coin-dev