Excellent video with plenty detail explanation. I do have one question though: With realtime systems we used to say - stay away from new object creations as much as possible. With records you do not have an option to adjust the data other than creating a new record, like you did in the beginning. With the improved GC's and serious horsepower we have nowadays, do you think it is still better to use a DTO with getter/setter and pass that around, or use records and simply return a new instance when you do need to adjust some data. Personally I find using records great as input and output carriers, and old-school DTO's inside the app between different services/layers (old old habits die hard!). As always not a hard rule.
Yeah, that's a legitimate debate. A lot of it comes down to immutability being so useful when concurrency is involved, because shared mutable state is so hard to get right. But I understand your concern
Looks almost like Rust, nice😀One more thing that I love about records is using record patterns to deconstruct their values, e.g. case Result.Success(var astronautsByCraft) -> processor.printResults(astronautsByCraft) or case Result.Failure(var error) -> System.out.println("Error: " + error);
Right, there are several monad-related interfaces similar to this (Try, Either, etc) that Java could use. Or maybe there will be a decent library at some point that will include them. I don't know what the delay is either (no pun intended).
Not better. More efficient. 🤔 OOP foundation remain the same which make programming easier to manage. We tested these in my Data Analysis Course. The majority approved this conclusion. 😊
I loved Brian's article, too few people know about the sealed interface with multiple records inside it tidbit.
Agreed. First time I saw the records inside the sealed interface, I thought it was a typo :-)
very interesting how you did the sealed interface with two records inside
Cool, right? Brian Goetz did it in his article and I didn't even realize that was legal until I saw him do it :-)
Excellent video with plenty detail explanation.
I do have one question though: With realtime systems we used to say - stay away from new object creations as much as possible. With records you do not have an option to adjust the data other than creating a new record, like you did in the beginning. With the improved GC's and serious horsepower we have nowadays, do you think it is still better to use a DTO with getter/setter and pass that around, or use records and simply return a new instance when you do need to adjust some data.
Personally I find using records great as input and output carriers, and old-school DTO's inside the app between different services/layers (old old habits die hard!). As always not a hard rule.
Yeah, that's a legitimate debate. A lot of it comes down to immutability being so useful when concurrency is involved, because shared mutable state is so hard to get right. But I understand your concern
Nice 👍
Thanks ✌
your content is very good
Thanks :)
Looks almost like Rust, nice😀One more thing that I love about records is using record patterns to deconstruct their values, e.g.
case Result.Success(var astronautsByCraft) -> processor.printResults(astronautsByCraft) or
case Result.Failure(var error) -> System.out.println("Error: " + error);
Nice example of record patterns, thanks. As for Rust, never heard of it 😉
Looking this amazing example I question myself why the hell Java did not bring the either interface of Scala. It would make so powerful.
Right, there are several monad-related interfaces similar to this (Try, Either, etc) that Java could use. Or maybe there will be a decent library at some point that will include them. I don't know what the delay is either (no pun intended).
Not better. More efficient. 🤔 OOP foundation remain the same which make programming easier to manage. We tested these in my Data Analysis Course. The majority approved this conclusion. 😊