davidalayachew

6 ms·

31.
by davidalayachew 3y ago
I think you have correctly identified the cost of aiming for long term, evergreen success -- you must sacrifice short term gain to get it. Yes, because records are still slowly being improved, it means that people will put together workarou
32.
by davidalayachew 3y ago
I learned how btw -- you email them at hn@ycombinator.com. 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.
33.
by davidalayachew 3y ago
I know we don't have the ability to follow/get notifications about a ticket, but we do have the ability to submit issues and comments by proxy! If you lack an account, go to the Java Bug Database -- https://bugs.java.co
34.
by davidalayachew 3y ago
Ty vm!
35.
by davidalayachew 3y ago
Also, I don't know how to use HN. How does one flag down a mod?
36.
by davidalayachew 3y ago
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
37.
by davidalayachew 3y ago
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 l
38.
by davidalayachew 3y ago
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 h
39.
by davidalayachew 3y ago
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 in
40.
by davidalayachew 3y ago
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 "reconstru
41.
by davidalayachew 3y ago
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 id
42.
JEP Draft – Derived Record Creation (Preview)(bugs.openjdk.org)
74 points by davidalayachew 3y ago|50 comments
43.
by davidalayachew 3y ago
The new Match<IN, COND_OUT> is one of my favorite parts of this proposal. It really makes patterns feel like a first-class citizen rather than just a weird amalgamation of a method. Now, it feels like almost anything that we can do wi
44.
by davidalayachew 3y ago
Let me make a completely unrelated and orthogonal observation that has nothing to do with this post. You see the url that is in the OP? This one. https://foon.uk/robin-allen-cv.pdf Copy that url, paste it into a new tab, bu
45.
by davidalayachew 3y ago
> Can you actually use them to use two different versions of library C in the same application yet though? Nope, this is functionality that Java (and thus, the module system) does not (yet) provide.
46.
by davidalayachew 3y ago
> Java Modules is the one that can't actually provide that functionality yet, right? You are correct. As of now, Java Modules have no way to disambiguate versions of the same dependency. This is intentional and by design. As far as
47.
by davidalayachew 3y ago
> OSGi and Java Modules would like a word. Hold on - the way you are phrasing this implies that Java Modules allow you to solve the version problem mentioned above. As in, your comment implies that Java Modules have a concept of version,