Comments on JDK-8198408 please ?

[Maurizio Cimadamore]

On the broad point I agree - withfield don't mix in well with Java 
assignment operator - and its side-effecting of the selected expression 
(the 'a' in 'a.x'). There might be other syntactic alternatives (postfix 
increment and the likes) which  might be more suitable to indicate the 
side-effecting nature, but ultimately, as John points out - this is a 
New Thing (TM).

If I had to take a guess, the problem with implementing multi-level 
withfields in javac is that, until the backend, they are just, well, 
assignments. I think that's the wrong AST form for such a construct. We 
should have a lowering step before getting to the backend which prepares 
the AST to a form which is more amenable to the withfield treatment. So 
if you have

a.b.c = x

this should be translated as:

__WithField(a.b, __WithField(b.c, x))

and the backend should then have an easier life. Incidentally, this form 
is also similar to what John suggested to use as a prototype - so 
perhaps a new experimental keyword and a new experimental AST node could 
be a good start here.

Once we have a new AST node - e.g.

class JCWithField extends JCExpression {
    JCExpression lvalue;
    JCExpression rvalue;
}

We have to decide what kind of 'lvalue' are admissible in such a 
construct. How many levels can the lvalue have? Can the lvalue contain 
complex expressions, as in:

__WithField(foo(x -> ...).g, 12)

I think for now it's better to start simple - only one level allowed and 
no complex expressions in the selector allowed. That means that lvalue 
should be restricted to a JCFieldAccess node, whose 'selected' part must 
be a JCIdent. This form should be close enough to what the bytecode can 
handle.

This means that some 'manual' desugaring would need to take place - but 
I think it's an acceptable trade off for now.

Maurizio



On 26/02/18 21:46, John Rose wrote:
> We could also represent withfield directly with a temporary
> extra operator:  __WithField(a.x, 11).  I think I'd prefer that,
> because it's more obviously a temporary expedient to be
> replaced later.  Would that be difficult to prototype in javac?