<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<blockquote type="cite" cite="mid:476261784.20721726.1768897040954.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div data-marker="__QUOTED_TEXT__">
<blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<blockquote cite="mid:1884486700.20372636.1768848050872.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div>
<div>The modifier "component" is too close to the
"property" modifier I wanted to include years ago,
it's just to sugary for its own good.</div>
</div>
</div>
</blockquote>
<br>
You know the rule; mention syntax and you forfeit the right
to more substantial comments....</blockquote>
<div><br>
</div>
<div>I'm talking about the semantics, especially the fact that
equals/hashCode and toString() are derived from.</div>
</div>
</div>
</blockquote>
<br>
Except that equals/hashCode have nothing to do with the "component"
modifier _at all_. They are derived from the _state description_,
in terms of the _accessors_, whose existence is implied directly by
the _state description_. <br>
<br>
If a concrete class (including records) have a state description,
then equality means "all the components are equal". The different
between carrier classes and records is the plumbing between the
representation and API; one can be automated, the other might
require manual assistance to complete. <br>
<br>
<blockquote type="cite" cite="mid:476261784.20721726.1768897040954.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div data-marker="__QUOTED_TEXT__">
<div>As far as i understand, the carrier class syntax </div>
<div> class Point(int x, int y) { ... }</div>
<div>means that</div>
<div>- if it's not a concrete class, the implementation should
provide an implementation for the canonical constructor and
accessors,</div>
<div>- if it's an interface or an abstract class, the
accessors are generated as abstract methods. </div>
<div><br data-mce-bogus="1">
</div>
<div>Then declaring a field as "component" generates the
canonical constructor, the corresponding accessor and
toString/equals/hashCode.</div>
</div>
</div>
</blockquote>
<br>
This isn't quite right. <br>
<br>
- The state description implies the existence of specific API
elements: canonical constructor (for constructible entities) and
accessors. <br>
- Deconstruction is derived from the accessors. <br>
- Since the state description is complete, the default
equals/hashCode/toString is again derived from the accessors (for
concrete entities). <br>
- If the user provides the required API elements, nothing else is
"generated". <br>
<br>
If the required API elements are not present, and they _can_ be
derived, they are. This is always true for records. For accessors,
this is true when the component is backed by a `component` field,
otherwise the compiler will force you to explicitly declare it. For
constructors, if _no_ constructor is specified, an empty compact
constructor will be derived. Further, for a compact constructor, if
a field is a component field, the component parameter will be
implicitly committed to the field at the end of the constructor. <br>
<br>
So the role of `component` fields is limited to two things: if there
is no accessor, you get one, and the compact constructor will
implicitly commit the field for you. A record is a carrier class
which has component fields for all components. <br>
<br>
<blockquote type="cite" cite="mid:476261784.20721726.1768897040954.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div data-marker="__QUOTED_TEXT__">
<div>As i said earlier, I think that providing an
implementation for toString/equals/hashCode is not a good
idea.</div>
</div>
</div>
</blockquote>
<br>
What this implies is that you you don't buy the (quite fundamental!)
notion that a record is a degenerate case of a carrier. Currently,
a record is equivalent to a carrier class that (a) extends Record,
(b) is final, and (c) has private final component fields for each
component. If you want to "separate" the default semantics of the
Object methods, you have to separate the notion of carrier from
records. Is that what you're suggesting?<br>
<br>
<blockquote type="cite" cite="mid:476261784.20721726.1768897040954.JavaMail.zimbra@univ-eiffel.fr">
<div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000">
<div data-marker="__QUOTED_TEXT__">
<div>Given that the class can be mutable, generating equals
and hashCode hide important details that are </div>
</div>
</div>
</blockquote>
<br>
Please stop saying "generate". (Actually, please stop *thinking*
it.) That's Lombok-think. <br>
<br>
<br>
</body>
</html>