[HN Gopher] Derived Record Creation (Preview)
___________________________________________________________________
Derived Record Creation (Preview)
Author : davidalayachew
Score : 50 points
Date : 2024-01-24 18:32 UTC (4 hours ago)
(HTM) web link (bugs.openjdk.org)
(TXT) w3m dump (bugs.openjdk.org)
| davidalayachew wrote:
| Java "withers" are on the way!
|
| 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!
| DarkNova6 wrote:
| Just recently, talks in the java amber mailing list emerged
| talking precisely about deconstruction of arbitrary classes.
| davidalayachew wrote:
| Yes, I think I was participating in those talks.
|
| 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.
| eweise wrote:
| Why wasn't this included in the initial records implementation?
| I tried records and quickly gave up after realizing there was
| no copy method. There's plenty of prior art. Scala has had this
| for twenty years. Java needs to stop shipping features that
| don't work as well as in other languages.
| pjmlp wrote:
| One step at a time, that is why.
|
| Scala is also on the edge of turning into Coffee Script, its
| relevance wanning.
|
| 20 years is pushing it, by the way.
| eweise wrote:
| Oh yes, 18 years. Guess that's not enough time. And yes,
| Scala's relevance is waining but not sure what that has to
| do with this topic. Kotlin also has a copy method if you
| need an example of a language doing well.
| davidalayachew wrote:
| The biggest reason why is because the Java team works as hard
| as possible to get as much user feedback before putting a
| feature out there.
|
| 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.
| ecshafer wrote:
| This looks like it could be a good change. Personally I think new
| point with { x = 1, y = 2, z = 3 } is much cleaner looking than
| say point.withX(1).withY(2).withZ(3). names params is generally
| something I like it languages though, so I might be biased here.
| tadfisher wrote:
| This concerns me: Point newLoc = oldLoc with
| { x *= 2; y *= 2; z *= 2;
| };
|
| It feels more like a mutable "Builder" class than a copy
| constructor. I guess the benefit is that you can do things like
| the above, instead of the following in Kotlin:
| val newLoc = oldLoc.copy( x = oldLoc.x * 2,
| y = oldLoc.y * 2, z = oldLoc.z * 2 )
|
| But in Kotlin it's more clear that oldLoc is immutable.
| rbehrends wrote:
| For what it's worth, in Kotlin you could also do the
| following: val newLoc = oldLoc.run { copy(x =
| x * 2, y = y * 2, z = z * 2) }
| inglor wrote:
| C# does this already https://learn.microsoft.com/en-
| us/dotnet/csharp/language-ref... - works pretty well. It's good
| that Java is finally getting more ergonomic these past few years.
| zokier wrote:
| The C# with seems bit more restricted though because it uses
| object initializer syntax while Java has full-blown code block,
| so in Java you can put arbitrary statements in. Also in Java
| you get the original values in the with statement, which I
| don't see in C#.
| lpapez wrote:
| They use Jira to track Java development? Well color me surprised.
| davidalayachew wrote:
| It is a bit clunky, but it makes things really traceable.
|
| The Java team even backported their old, historical
| bugs/requests-for-enhancement into JIRA. You can see feature
| requests from the late 90's in there. Plus, you can write
| little SQL-esque queries to filter down submissions to just
| what you want.
|
| So, true to Java form -- it's clunky, but the value is real.
| pulse7 wrote:
| The proposed syntax is not intuitive... How can I know to which
| records x, y and z are refering to in: Point newLoc = oldLoc with
| { x _= 2; y_ = 2; z *= 2; } ? And in this case "return this with
| { im = -im; };" - which "im" goes to which record? Please make
| more intuitive syntax for this!
| davidalayachew wrote:
| The general idea behind JEP Drafts such as these is that they
| first focus on the semantics -- what can/should this feature
| do?
|
| 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.
| davidalayachew wrote:
| Could a moderator change the title back to at least include the
| phrase JEP Draft?
|
| 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.
| davidalayachew wrote:
| Also, I don't know how to use HN. How does one flag down a mod?
___________________________________________________________________
(page generated 2024-01-24 23:00 UTC)