Campbell Ritchie wrote:You have already suggested a much better feature suitable for that sort of objects: records.
Yehonathan Sharvit wrote:
For information systems that deal with information of dynamic nature, this tradeoff might make sense in some parts of the coded, even if it's not natural for Java developers.
Suppose you need to represent the data of a JIRA ticket with fields like: title, author, priority etc.. in addition to custom fields that are defined by the user. How would you store those fields as members of a class whose layout is defined at compile time in Java?
Yehonathan Sharvit wrote:
Let me give you a couple of benefits of this unified approach to data:
Get an attribute with myJiraTicket.get("myCustomAttribute") without the need to know if it's a custom attribute or a regular attribute.
Count the number of attributes without any custom codde
Serialize a JIRA ticket to JSON without any custom code Duplicate a JIRA ticket to JSON without any custom code
I am not saying that you should this approach everywhere in Java. I am trying to illustrate what are the benefits of this approach in order to discover together what are the situations and use cases where it makes sense to trade off type safety for data access flexibility.
Yehonathan Sharvit wrote:
Data is represented with Java 14 records
Yehonathan Sharvit wrote:
Code is stored in static methods
Immutable objects have all sorts of advantages, including thread‑safety. It is easy enough to change data, but you need a new instance:-That is how you alter data in any immutable kind of object. Maybe in the good old days of JDK1.0.2 and big PCs having 16MB of RAM, it would be a performance bottleneck or memory hog, but those days are long past.Claude Moore wrote:. . . . The only drawback i can see with records is that they're immutable. . . . . When you read data from somewhere, you'll want to manipulate them. . . . helper methods to accomplish a simple task - change a value. . . .
Immutable objects have all sorts of advantages
Campbell Ritchie wrote:That would work, but you now have coupling between the two classes. It is like what Claude Moore said earlier: a C struct and functions to operate it.
Do you think I'd have noticed that if I'd looked at the diagram properly?Mike Simmons wrote:Campbell, I don't think any of the relations in that diagram are inheritance. . . .
Yehonathan Sharvit wrote:Ok. Let's say that for now, having a flexible access to data is not beneficial enough to a Java developer so that he is willing to trade off type safety for it.
Yehonathan Sharvit wrote:When about the other approach presented in the article where:
Data is represented with Java 14 records Code is stored in static methods
Do you guys think that it could help reducing the complexity of Java programs?
Mike Simmons wrote:
This does have some appeal. Given that records are "official" now (not a preview version), I'm eager to use them to present concise, clean representations of data, without the clutter. I'm fine with moving the methods elsewhere. You may see some resistance to the idea of all methods being static though... mostly from a testability perspective. If a complex method relies on several other complex methods to function, we often want to mock out the other methods to better test one method at a time. So you may want to not insist on methods being static necessarily. They can be instance methods on a singleton-like object that can be mocked out. That may be more agreeable to many Java developers.
Yehonathan Sharvit wrote:Based on your reactions in this thread, I wrote a blog post to illustrate various ways of providing dynamic data access in Java.
Looking forward to get your feedback.
Checked exceptions are brilliant () . . . until you stray the slightest way beyond the bounds of strict object‑oriented (=OO) programming. Functions can't cope with checked exceptions, which is why the Streams API (java.util.stream.Stream, etc.) wraps all their exceptions in unchecked exceptions. Classic unchecked example. Actually, functions shouldn't permit exceptions full stop. This means that Oracle aren't doing what it says about exceptions in the Java™ Tutorials.Mike Simmons wrote:. . .
I hate checked exceptions . . . let's wrap the checked exceptions with some kind of RuntimeException. . . .
What a nice idea. it looks very similar to OptionalXXX#orElse(). It also brings me out in spots. I have gradually developed an allergy to primitives in an OO language. Primitives are all right as long as you confien yourself to arithmetic etc., but as soon as you try anything more complicated, you have to use sentinel results. This is one of the oldest examples of a sentinel result, which probably predates Kernighan and Ritchie; at least in this instance you can be sure that the sentinel result can't be a “real” result, but zero/null char/false are perfectly acceptable “real” results in some circumstances.. . . primitive converters that replace null will the default value - so getInt() returns 0 . . . .
Another good feature. . . The programmer can choose which they want.
Yehonathan Sharvit wrote:Could you elaborate further on what you wrote about type inference and give an example?
Campbell Ritchie wrote:Very interesting point there. But isn't that the equivalent of using a raw type?
Campbell Ritchie wrote:If you made the parameter type T, that would very simply give you type‑safety back.
Seriously Rick? Seriously? You might as well just read this tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
|