State of javac support for lworld-values.

[Srikanth]

On Thursday 15 March 2018 11:53 PM, Karen Kinnear wrote:

[...]

>> Thanks for writing that down, Karen.
>>
>>>
>>> I believe there are two major open issues:
>>> 1. you identified one - which is the discussion around <init>, which 
>>> I think also includes
>>> handling of __MakeDefault
>>
>> Yes, we haven't touched <init> yet.  I think the language folks need to
>> decide what value constructors look like before we can start to talk
>> translation strategy.  My crystal ball tells me that <init> will be 
>> irrelevant
>> to value types, even though at the source level constructors will be
>> important.  ("Codes like a class…")  The JVM rules around <init> are
>> just relentlessly pointer-oriented, so we'll probably break new ground
>> for value factories.  (If we win big, then that ground will serve for
>> factories on object classes and interfaces too, but that's just my
>> hunch for now.)
> Is there an rfe here?
> So how does instance initialization happen for testing right now 
> before this gets resolved?

Here is the present state at the language level:

ATM, javac does continue to generate <init> methods - these are useless 
of course and are not called at all. However, source constructors do 
play a role in satisfying the "code will not compile unless the all 
final fields have been initialized before the constructor finishes" rule.

Attempting to do:

     new ValueType([args])

will result in a compile error and one will have to change the code to

      __MakeDefault ValueType();

(attempting to invoke __MakeDefault while passing arguments will result 
in a compile error)

So, the only way to instantiate value instances is by producing default 
values and then applying withfield on them successively as needed.

This is obviously an interim point. I believe it does allow us to test 
without solving the full question of the role of source constructors and 
factories.

Srikanth