On 2017-11-03T13:19:09 +0100 [email protected] wrote: > > Yes, the point is about encapsulation, boundaries, as you have written. > We used to insert Objects.requireNonNull at the start of public methods to > validate preconditions, given that the primary constructor of a data class is > now generated, the question is how to tell the compiler to generate those > precondition for me.
Having played around with the prototype today, I have to say that I think Rémi might be right! It's what I think of as the Haskell effect: When you have a language with very terse syntax, every single piece of boilerplate you have to write seems a lot worse than it otherwise would. If you take a look at a typical Haskell file, it somewhat ironically feels as though there's quite a bit of boilerplate (typeclass instances, module export lists, matching on record values, signatures to some extent) because the rest of the language requires so few keystrokes. Having used data classes a little, I can see that I'm now almost never going to use the default constructor because I always want to insert calls to Objects.requireNonNull(...). Those have become the new mildly annoying boilerplate (and yet I'm used to having to write them over and over by hand in normal classes today). -- Mark Raynsford | http://www.io7m.com
