Data classes

[Mark Raynsford]

On 2017-11-03T13:19:09 +0100
forax at univ-mlv.fr 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