4 ms·

What I meant was that we don't adopt a feature just because some other language has it, let alone from languages that don't have the same philosophy as we do of

by pron 4y ago

What I meant was that we don't adopt a feature just because some other language has it, let alone from languages that don't have the same philosophy as we do of trying to have as few features as we can get away with. Records are overall more valuable than properties (due to various reasons, from serialization to interaction with collections). But once you have records with "withers" the question becomes how valuable is it to also have properties. It doesn't seem like it would be helpful enough to overcome the drawbacks. BTW, C# didn't add properties as a "lesson." Properties in C# and JavaBeans have the same pedigree: RAD UI composer tools of the 90s [1]. They came to C# by way of VB. So really, Java would be adopting a VB solution, and there needs to be a good reason for that. [1]: https://en.wikipedia.org/wiki/Rapid_application_development https://en.wikipedia.org/wiki/Rapid_application_development

dmitriid 4y ago
> and there needs to be a good reason for that. A year ago I already said all the good reasons. There are many reasons why things like Lombock exist. There are reasons why people loathe writing interminable chains of builder methods. But sure. None of these are good reasons because something something Visual Basic. What Java will inevitably end up with is a yet another half-assed approach that only exists for a small part of the language and is not applicable to the rest of it. > BTW, C# didn't add properties as a "lesson." That's not what I wrote. This is literally from your link: "Digression: learning from C#" And look. Right below it, emphasis mine --- start quote --- The C# approach was sensible for them because they could build on features they already had (default parameters, properties) --- end quote --- And look. "Extrapolating from records" section basically says: Java has nothing, and will need to rebuild everything from scratch for this not to be a half-assed solution. Oh well.
- pron 4y ago
  > The C# approach was sensible for them because they could build on features they already had (default parameters, properties) You've misunderstood. Once you have properties it makes sense to go a certain way. If you don't, it makes more sense to add records and not properties. Now you don't have to agree with the Java team's decisions. Programmers rarely agree on much. But I think you should at least appreciate the irony that if we had added properties, I would be responding right now to another equally annoyed person complaining that we're not learning the lessons of Go and Zig and Rust, which have refused to add properties, and couldn't we see what an obviously stupid idea it was.
  - dmitriid 4y ago
    > But I think you should at least appreciate the irony that if we had added properties, I would be responding right now to another equally annoyed person complaining that we're not learning the lessons of Go and Zig and Rust Most likely not. Meanwhile C# could build on the strength of what they have in the language. And Java, and I cannot repeat it enough times, will have a half-assed solution applicable only to a small part of the language while keeping the inanity of manual `.of` methods, manual interminable chains of builder methods, and other half-assed solutions everywhere else. While denigrating other languages and their decisions. Even the link you provided clearly states this: "And, everything we can do with records but not with classes increases a gap where users might feel they have to make a hard choice; it's time to start charting the path of generalizing the record "goodies" so that suitable classes can join in the fun." Again: while others have built on the languages features they have, and they are immediately propagated through the language with little to no additional effort, "Java does not adopt strategies from less successful products", and "keep the language conservative". And yet here we are, "learning from C#" and struggling how to figure out a simple (for some definition of simple) addition so that it works with the rest of the language that has languished in the "conservative" land for too long. Edit. I also wonder how many of the things that are currently placeholders will be required and will surpass anything C# and other "lesser languages" have come up with: factory, __byname, __deconstructor etc.
    - pron 4y ago
      Out of curiosity: given that virtually all features in Java were adopted from other languages (almost always less popular ones) so there clearly is no aversion to that, and given the level of experience and success of the Java team, not to mention their clear interest in Java's success -- i.e. they have both the motivation and ability to do what's best for Java -- what possible reason do you think they have to do something that to you seems so obviously wrong? Moreover, why do you conclude that propertied are the only right choice, seeing that Java is far from being the only language without them? You should, at best, conclude that some language designers like them and some don't. > Even the link you provided clearly states this: ... That refers to pattern matching and withers. Records don't have properties either.
- wtetzner 4y ago
  I don’t think properties add anything that getters/setters don’t already give you (other than slightly different syntax). I think the “right” way to replace the need for builders is to add support for named arguments.
  - dmitriid 4y ago
    > I don’t think properties add anything that getters/setters don’t already give you Except that you have to write them out by hand for every property you want in your code. Or generate them. > I think the “right” way to replace the need for builders is to add support for named arguments. Often you want to add validators to your setters. Just named arguments won't cut it.
    - wtetzner 4y ago
      > Often you want to add validators to your setters. Just named arguments won't cut it. Are you suggesting that arguments can’t be validated in a constructor? I don’t think I’m following the argument.
    - pron 4y ago
      > Except that you have to write them out by hand for every property you want in your code. Or generate them. Our analysis has determined that the vast majority of getters and setters are used in classes that are better replaced by records anyway (with all the benefits records bring that go far beyond conciseness, such as safe serialization and correct interaction with collections). The remaining cases are not numerous enough to pose a large enough problem that justifies an ad-hoc language construct, but could be further helped by a more general mechanism, such as concise method bodies (https://openjdk.org/jeps/8209434 https://openjdk.org/jeps/8209434). The result is a smaller number of much more powerful features. In other words, rather than making getters and setters easier to write, we simply get rid of the need for most of them altogether, which not only saves us a language feature, but also the downsides that setters and getters (or properties) have. We preferred tackling the problem at its source by asking what causes the need to write so many getters and setters in the first place (Java's lack of good data manipulation constructs) rather than treating the symptom (writing getters and setters is tedious).

by pron 4y ago

dmitriid 4y ago

> and there needs to be a good reason for that. A year ago I already said all the good reasons. There are many reasons why things like Lombock exist. There are reasons why people loathe writing interminable chains of builder methods. But sure. None of these are good reasons because something something Visual Basic. What Java will inevitably end up with is a yet another half-assed approach that only exists for a small part of the language and is not applicable to the rest of it. > BTW, C# didn't add properties as a "lesson." That's not what I wrote. This is literally from your link: "Digression: learning from C#" And look. Right below it, emphasis mine --- start quote --- The C# approach was sensible for them because they could build on features they already had (default parameters, properties) --- end quote --- And look. "Extrapolating from records" section basically says: Java has nothing, and will need to rebuild everything from scratch for this not to be a half-assed solution. Oh well.

pron 4y ago
> The C# approach was sensible for them because they could build on features they already had (default parameters, properties) You've misunderstood. Once you have properties it makes sense to go a certain way. If you don't, it makes more sense to add records and not properties. Now you don't have to agree with the Java team's decisions. Programmers rarely agree on much. But I think you should at least appreciate the irony that if we had added properties, I would be responding right now to another equally annoyed person complaining that we're not learning the lessons of Go and Zig and Rust, which have refused to add properties, and couldn't we see what an obviously stupid idea it was.
- dmitriid 4y ago
  > But I think you should at least appreciate the irony that if we had added properties, I would be responding right now to another equally annoyed person complaining that we're not learning the lessons of Go and Zig and Rust Most likely not. Meanwhile C# could build on the strength of what they have in the language. And Java, and I cannot repeat it enough times, will have a half-assed solution applicable only to a small part of the language while keeping the inanity of manual `.of` methods, manual interminable chains of builder methods, and other half-assed solutions everywhere else. While denigrating other languages and their decisions. Even the link you provided clearly states this: "And, everything we can do with records but not with classes increases a gap where users might feel they have to make a hard choice; it's time to start charting the path of generalizing the record "goodies" so that suitable classes can join in the fun." Again: while others have built on the languages features they have, and they are immediately propagated through the language with little to no additional effort, "Java does not adopt strategies from less successful products", and "keep the language conservative". And yet here we are, "learning from C#" and struggling how to figure out a simple (for some definition of simple) addition so that it works with the rest of the language that has languished in the "conservative" land for too long. Edit. I also wonder how many of the things that are currently placeholders will be required and will surpass anything C# and other "lesser languages" have come up with: factory, __byname, __deconstructor etc.
  - pron 4y ago
    Out of curiosity: given that virtually all features in Java were adopted from other languages (almost always less popular ones) so there clearly is no aversion to that, and given the level of experience and success of the Java team, not to mention their clear interest in Java's success -- i.e. they have both the motivation and ability to do what's best for Java -- what possible reason do you think they have to do something that to you seems so obviously wrong? Moreover, why do you conclude that propertied are the only right choice, seeing that Java is far from being the only language without them? You should, at best, conclude that some language designers like them and some don't. > Even the link you provided clearly states this: ... That refers to pattern matching and withers. Records don't have properties either.
wtetzner 4y ago
I don’t think properties add anything that getters/setters don’t already give you (other than slightly different syntax). I think the “right” way to replace the need for builders is to add support for named arguments.
- dmitriid 4y ago
  > I don’t think properties add anything that getters/setters don’t already give you Except that you have to write them out by hand for every property you want in your code. Or generate them. > I think the “right” way to replace the need for builders is to add support for named arguments. Often you want to add validators to your setters. Just named arguments won't cut it.
  - wtetzner 4y ago
    > Often you want to add validators to your setters. Just named arguments won't cut it. Are you suggesting that arguments can’t be validated in a constructor? I don’t think I’m following the argument.
  - pron 4y ago
    > Except that you have to write them out by hand for every property you want in your code. Or generate them. Our analysis has determined that the vast majority of getters and setters are used in classes that are better replaced by records anyway (with all the benefits records bring that go far beyond conciseness, such as safe serialization and correct interaction with collections). The remaining cases are not numerous enough to pose a large enough problem that justifies an ad-hoc language construct, but could be further helped by a more general mechanism, such as concise method bodies (https://openjdk.org/jeps/8209434 https://openjdk.org/jeps/8209434). The result is a smaller number of much more powerful features. In other words, rather than making getters and setters easier to write, we simply get rid of the need for most of them altogether, which not only saves us a language feature, but also the downsides that setters and getters (or properties) have. We preferred tackling the problem at its source by asking what causes the need to write so many getters and setters in the first place (Java's lack of good data manipulation constructs) rather than treating the symptom (writing getters and setters is tedious).