121–130 of 294 posts
Earlier quoted context omitted.
> so it is kind of only of academic value if a field in a POD, POJO, POCO or whatever it is called in the specific language actually may change. I'm not sure if you've debugged much, or inherited any large legacy projects, but knowing it is immutable vs "typically it isn't" is a pretty big distinction in that moment.
Good code don't have this issue.
Not sure why immutable data structures have surfaced as something important. Typically you never change fields so it is kind of only of academic value if a field in a POD, POJO, POCO or whatever it is called in the specific language actually may change.
Keyword being “may”. Guarantees are nice. Especially if objects are going to be passed around every which way from Sunday. It allows you to better reason about what could happen, and where. Java has taken a while to get there, but I’m glad that they have finally.
Earlier quoted context omitted.
"Typically" this means you can never be sure, which is a problem.
Sure of what? If your code is not garbage it takes two seconds to see where things change. It should be very places in the code.
Earlier quoted context omitted.
How's your experience with C#/.NET been? Does it have an analogous offering to Java's JFR[0] for always-on profiling? [0] https://blogs.oracle.com/javamagazine/java-flight-recorder-a...
Seems like EventPipe is the C# equivalent? https://docs.microsoft.com/en-us/dotnet/core/diagnostics/eve...
I give it 5-10 years before we've tricked everyone into writing OCaml / F#!
Earlier quoted context omitted.
In languages without property support, reflexively writing getters and setters is the only way to make it possible to go back later and add logic to getting and setting without changing the callsites. Is this a workaround for the combined shackles of mismanaged enterprise environments where changing callsites is impossible for some reason, and legacy language environments where you have to use Java for some reason? Y…
> go back later and add logic to getting and setting Which, realistically, you're virtually never going to do - at least not often enough to justify the boilerplate and especially in the case of things like "records" which were probably auto-generated from a schema (with obligatory getters and setters) anyway. If you did , you'd end up confusing all of your callers who probably wrote client code presuming that what t…
I'm not sure what it's taking about for the "with" feature: https://nipafx.dev/java-record-semantics/#with-blocks In Kotlin data classes, it's already implemented (just called copy) https://kotlinlang.org/docs/data-classes.html#copying
https://devblogs.microsoft.com/dotnet/c-9-0-on-the-record/#w...
I think the author is more saying that a "with" operator would fit into Java record semantics but might not be compatible with Lombok @Data classes or Kotlin data classes (though it looks from your link that Kotlin actually does have something very similar in the "copy" method).
Earlier quoted context omitted.
Or you know, the JIT will trivially optimize away the old class if it is reassigned to the same variable, as you would use it inside a loop. How do you think the litany of FP languages work? Like Haskell, Scala, Clojure?
It can be done in theory, but the JVM does nothing of the sort right now.
Earlier quoted context omitted.
Seems like EventPipe is the C# equivalent? https://docs.microsoft.com/en-us/dotnet/core/diagnostics/eve...
It seems somewhat similar, but I don't see mention of method traces (similar to a profile view in figure 7 in the blog post I listed).