Reference implementation

[Jonathan Gibbons]

Neal,

Maurizio defined these terms in emails to coin-dev round about Aug 22.

"simple" and "complex" are defined here:
http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002159.html

I believe "full-complex" first appeared here:
http://mail.openjdk.java.net/pipermail/coin-dev/2009-August/002165.html

I'll leave Maurizio to provide any updates on the terminology.

-- Jon



Neal Gafter wrote:
> Maurizio:
>
> Can you please define the "complex", "simple", and "full-complex"
> approaches?  Which is used in the current implementation?  Which approach
> can support inference in argument contexts (i.e. part occurs before overload
> resolution, part after)?
>
> Cheers,
> Neal
>
> On Mon, Oct 26, 2009 at 10:04 AM, Maurizio Cimadamore <
> Maurizio.Cimadamore at sun.com> wrote:
>
>   
>> Paul Benedict wrote:
>>     
>>> Neal,
>>>
>>> Thank you for raising this point again!
>>>
>>> It was admitted the current diamond operator implementation is
>>> incomplete compared to the "complex/full" solution. It was also
>>> admitted the partial solution is not a "true subset" of the "complex"
>>> solution. With that said, I am concerned the partial solution will
>>> infer somethings in JDK 7, but a later JDK using the "complex"
>>> solution would infer differently or invalidate inferences of the
>>> partial solution. Joe, is that possible?
>>>
>>>       
>> Both complex and simple are subset of full-complex. If some future
>> release will switch to full-complex the transition will be smooth (no
>> strange mismatch in types inferred by the diamond algotithm). On the
>> other hand switching from simple to complex and vice-versa will cause
>> problems.
>>
>> Maurizio
>>     
>>> Paul
>>>
>>>
>>>       
>>
>>     
>
>