I am very excited for this feature and has been a long time coming. This will make immutable transformation code much easier to write and reason about.
That said, I'm a little uneasy with the idea that we don't even have the option to write out our deconstruction pattern. That feels like a foot gun. I know that records come pre-baked with a deconstructor, I'm not asking to be able to choose. I am more asking for the ability to see the variable that I am overwriting. And I am not asking that every Java developer should have to shoulder that burden -- keep it implicit for those who want it. But I feel uneasy that I don't even have the option to write out the variables in my deconstructor.
I will try it out before taking issue with it, but these are my initial, uninformed feelings from looking at it. Regardless, even if my fears become true, this feature is well worth it, and I'm very happy to have it!
That does raise a good point -- If this concept might one day go over to the every day class, it sounds like they might be forced to list the deconstruction pattern used to do "reconstruction".
Either way, my main point is that -- the implicitness of this feature is appreciated, but I don't know if I want to be forced between implicit or just not using this feature, since my uninformed gut feels like I would appreciate the explicit clarity of seeing the variables I am working with. It might feel like a step back, but again, this is my opinion before having a chance to try this thing.
Part of that means that they will release minimal versions of a feature (records), and then observe how people use them before they start adding the "obvious" Quality-of-Life changes.
It's painful for those of us who are here when these features are just now releasing. But the end result is a feature that has less chance of screwing over other potential features.
It's best to think of it as a short term cost for a much longer term gain. Moving slow like this means that they will release a feature that is more cohesive than it otherwise could be.
Scala is also on the edge of turning into Coffee Script, its relevance wanning.
20 years is pushing it, by the way.
That is important because it communicates that this feature is actually not yet in Preview, but is on its way to being that.
Being in the JEP Draft state sets expectations about what part of this proposal is up for debate and criticism, and what parts are merely placeholder until the "heavier topics" have been hammered out.
Because you changed the title to this, it is actually not communicating the true intent, and thus, might invite discussion (read - criticisms) that this JEP Draft was never meant to contest.
A shame that you can't ping them directly through this application (like you can in Reddit), but the response time was quick, so that is appreciated.
https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
Point newLoc = oldLoc with {
x *= 2;
y *= 2;
z *= 2;
};
val newLoc = oldLoc.copy(
x = oldLoc.x * 2,
y = oldLoc.y * 2,
z = oldLoc.z * 2
)
val newLoc = oldLoc.run { copy(x = x * 2, y = y * 2, z = z * 2) }It should be 1 of the above. They also made the same weird new syntax choice with string template.
One of the most important things about a language is coherence and consistency. That’s why a language designer is a role/talent
They save things like syntax until the very end, right before they decide to submit this as an actual JEP instead of a JEP Draft. This JEP entered the Draft stage only a few hours ago.
All that is to say -- your comment makes sense, but you are criticizing the part of this JEP Draft that is not only the least relevant to the discussion, but the thing that is most likely to change before it exits the Draft stage. Oftentimes, they even put in placeholder syntax to highlight this fact.
I'd limit criticisms of syntax until they submit this JEP for actual review.
Seems very intuitive to me (and same as C#).