Feedback on LW1 EAR

[Srikanth]

On Saturday 18 August 2018 04:10 PM, Uberto Barbini wrote:
> Good morning,
>
>
> I've played a bit in these days with the EAR and here is my feedback.

Thanks a lot. I'll add to Remi's answers with insight from Javac's work 
items list.
> 1) I saw there I can create Value Types using makeDefault + setField in a
> static method or I can use the "normal" new Value() syntax?
> The byte code produced seems identical:
> 4 invokestatic #3 <com/gamasoft/Point.$makeValue$>
> Is there a difference or a preference for the future?

For LW1 EAR we wanted to allow only the new ValueType() syntax and push 
the programmer level usage of __MakeDefault and __WithField under a 
compile time flag, but ran out of time. So I would say there is an 
inclination to prefer the classic/canonical construction notation (CCN). 
However as Remi alluded to, syntax details are subject to change.

>
> 2) Currently == won't compile. It will work eventually? It would be nice to
> be able to control a few of operator (== + - * / say)...
Operator overloading is a separate subject altogether - there are many 
other issues relating to value types that are vying for the lions share 
of language designer's time I would say.

Specifically speaking of `=='

in the very near term, javac will begin to tolerate certain idioms that 
it forbids today: viz if (v1 == v2 || v1.equals(v2)) (what we internally 
call "LIFE" - the legacy idiom for equality")

In slightly longer term, we are also asking the question whether == 
should simply be translated into the equals method call by javac where 
it can statically discern the operands to be values.

> 3) in the declaration
> final __ByVal public class
> final seems to be optional. Will it stay so?
Syntax details are subject to change, but I will share here that the 
final keyword was expressly required till very recently. That gives an 
indication of the present thinking.
> 5) I saw that I can override toString() and call super.toString() to have
> the standard Object behavior.
This should have been rejected by javac. That it is not is a defect I 
would say.

Srikanth