<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<font face="Times New Roman">Hello,<br>
I apologise for coming late to the party here - Records have been
of limited use to me but Mr Goetz's email on carrier classes is
something that would be very useful so I've been thinking about
the consequences.<br>
<br>
Since carrier classes and records are for data, in a database
application somewhere or other you're going to get database ids in
records:<br>
record MyRec(int dbId, String name,...)<br>
<br>
While everything is immutable this is fine but JEP 468 opens up
the possibility of mutation:<br>
<br>
</font><font face="Times New Roman">MyRec rec</font><font
face="Times New Roman"> = readDatabase(...);<br>
rec = rec with {name="...";};<br>
writeDatabase(rec);<br>
<br>
which is absolutely fine and what an application wants to do.
But:<br>
</font><font face="Times New Roman">MyRec </font><font
face="Times New Roman">rec = readDatabase(...);<br>
rec = rec with {dbId++;};<br>
writeDatabase(rec);<br>
<br>
is disastrous. There's no way the canonical constructor invoked
from 'with' can detect stupidity nor can whatever the database
access layer does.<br>
<br>
In the old days, the lack of a 'setter' would usually prevent
stupid code - the above could be achieved, obviously, but the code
is devious enough to make people stop and think (one hopes).<br>
<br>
Here there is nothing to say "do not update this!!!" except code
comments, JavaDoc and naming conventions.<br>
<br>
It's not always obvious which fields may or may not be changed in
the application.<br>
<br>
record </font><font face="Times New Roman">MyRec(int dbId, int
fatherId,...)<br>
probably doesn't want<br>
rec = rec with { fatherId = ... }<br>
<br>
but a HR application will need to be able to do:<br>
<br>
record </font><font face="Times New Roman">MyRec(int dbId, int
departmentId, ...);<br>
...<br>
rec = rec with { </font><font face="Times New Roman">departmentId
= newDept; };<br>
<br>
Clearly, people can always write stupid code (guilty...) and the
current state of play obviously allows the possibility (rec = new
MyRec(rec.dbId++, ...);) which is enough to stop people using
records here but carrier classes will be very tempting and that
brings derived creation back to the fore.<br>
<br>
It's not just database ids which might need restricting from
update, e.g. timestamps (which are better done in the database
layer) and no doubt different applications will have their own
business case restrictions.<br>
<br>
Thank you for your time,<br>
Andy Gegg<br>
</font><br>
</body>
</html>