Comments on JDK-8198408 please ?

Srikanth srikanth.adayapalam at oracle.com
Tue Feb 27 08:50:04 UTC 2018



On Tuesday 27 February 2018 06:43 AM, John Rose wrote:
> On Feb 26, 2018, at 4:50 PM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>
>>>>
>>>> I think for now it's better to start simple - only one level 
>>>> allowed and no complex expressions in the selector allowed.
>>>
>>> I don't think there is really a technical reason for this; but of 
>>> course is there is one,
>>> make it simpler by restricting the construct.
>> I agree there's no technical reason to have the restriction - and I 
>> did not propose the restriction because of that - I was only putting 
>> that restriction forward to allow for a 'staged' prototype - e.g. we 
>> can start simple, and add more complex forms as we go, and as we see fit.
>>
>> And no - I did not want an implicit write-back - if user wants 
>> writeback it should do that explicitly:
>>
>> A a = _WithField(a.x, 11);
>
> Got it!  Although I think you didn't mean to make a declaration only?
>
> A a = …;
> a = __WithField(a.x, 11);

The proposal for an explicit __WithField operator with no implicit 
write-back semantics looks so much better at first glance. I'll 
prototype that and see.

FTR and FWIW, on branch tip, withfield emission happens on field 
assignments of the form x.y = <val>
where x is required to a non-final handle.

Which would mean this.y = <val> would not work. Not the implicit this 
(with x being absent). All fancier cases are rejected.

Thanks gentlemen.
Srikanth

>
> — John
>
> P.S. And if we get reconstructor expressions, then such expressions
> would sugar up to something very vaguely like and yet unlike:
>
> b = a __Recon-> x = 10;  // a unchanged, b gets new version of a
> a = a __Recon-> x = 11;  // a gets new version of itself
> a __Recon->= x = 11;  // same as prev
> a = a __Recon-> x++;  // now a.x = 12
> a = a __Recon-> { x = 13; unlucky = true; log("shark jumped"); };
>
> (The reconstructor bodies set fields in exactly the same sense that
> constructors set blank final fields, except that reconstructors also
> provide the previous values of those fields in the previous version
> of the receiver.  If it is further aligned with constructor bodies, it
> can call methods ont the current object, like "log" above.)
>



More information about the valhalla-dev mailing list