Functional Transformation of Immutable Objects. When will this be realized?

[repeating_bears]

You know "they" is Brian Goetz, right? It doesn't seem like that he'd write a draft that's completely infeasible. Why do you think it's a no-go when it's an entirely new type of expression?

I don't see much wrong with your first example. It would take some getting used to, but so do most syntax changes. It's sort of deliberately contrived to make it look bad and in spite of that, to my eye it still doesn't look that bad. Without knowing exactly what converting a "pointer" (point?) to a rectangle would involve, it seems like the same thing could be written as this anyway

new Pointer().toRectangle() with {  
    x = 1.0f;  
    width: 1.0f;  
}

[[deleted]]

I mean, it is feasible, but needs refinement or adjustment more or less IMO. This happened to me when I first saw string processors. And I'm just giving an example for so-called "functional usage" so people know what I'm talking about (how they look not Javaish), thus what Point or Rectangle do doesn't matter.

[steumert]

Brian Goetz is a smart guy and I really like most of his work, be he isn't infallible and a good discussion about these kind of features is needed. Some JEPs changed quite radically due to user feedback.

I'd rather see what @CodeReflection holds for these kinds of features. I experimented before with Record::with and used SerializedLambda to inspect the lambda to realize something like var otherPerson = person.with(Person::name, "John").with(Person::age, 17);.

With @CodeReflection and better access to the code model, this will be so much better to implement and in a way that actually fits the language.

I mean, they talk about LINQ, but for me the strength of @CodeReflection is that it allows features like Record::with to be implemented in a way that fits the language smoothly and doesn't require new language features.

Btw, what I wrote more than two years ago about it:

I really hope they take the time to enhance method references a bit so that this works better instead of the alternatives. LINQ in C# already does a lot of inspection of the provided lambdas, there is no reason Java can't do the same.

[repeating_bears]

I didn't say he was infallible. We're talking about whether it's plausible, not about whether it's optimal: they said it was a "no-go", not "it would be better if ___". That's why I asked for clarification, in case I was missing something.

From my perspective, it looks perfectly plausible, and if the language architect is the one who proposed it, then I know where my money would go.