Updated document on data classes and sealed types

[Brian Goetz]

> 
> Okay, mutable field types happen, and I can't think of any other reasonable approach besides allowing accessor overrides.

Yes, shaking your first and shouting “damn you, pervasive mutability” into the void (because that’s where the side effects live, of course) is a perfectly rational response.  

>  
> There’s another consideration, too.  We considered outlawing overriding the equals/hashCode method.  This goes a long way towards enforcing the desired invariants, but again seems pretty restrictive.
> 
> Yes, it's restrictive, and restrictiveness is what's great about records. Is this decision based on compelling use cases or on "seems pretty restrictive”?

Now that you are caught in the grasp of pervasive mutability, here’s another shake.  

For a well-behaved record R(x,y) and an instance `r`, it seems pretty reasonable to expect that new R(r.x(), r.y()) equals r.  If we have

     record KevinHatesLife(int[] ints) { }

and we take the default accessor and equals, this will be true, but we’ll be leaking our mutability.  There exist cases where that’s OK and desired, but there are cases when we want to not be leaky.  So we override the ints() accessor to clone on the way out.  But now, when we deconstruct-and-reconstruct, the new KHL is not equal to the old one.  To restore the desired equality semantics, we want to override equals as follows:

    boolean equals(Other o) { 
        return (o instanceof KevinHatesLife(var is)) && Arrays.equals(ints, is);
    }

(and of course the same for hashCode.)  Seems mean to not let you define equality in this way.  

Say it with me: “DAMN YOU, PERVASIVE MUTABILITY!"

> 
> I'm a bit relieved to hear this. The document seemed to imply that you would assign to the field, then later the remaining fields that weren't DA would be set from the remaining parameters. I think parameter reassignment is superior because there are never two versions of the data in scope at the same time. (I think the argument against parameter reassignment is mainly that it's heresy.)

Yes!  While it may seem more “efficient” to just write to the field directly, it would make things much more complicated.  If our ctor was

     Foo { 
          if (x < 0) 
              this.x = 0;
     }

now on exit from the ctor, this.x is neither DA nor DU, so the compiler would have to generate some pretty nasty code to replicate the conditions under which it would want to do the assignment.  So either the user-written ctor always writes the field (DA), or never does (DU) — or it’s an error.  

> 
> 
> The stricture against derived fields was probably the hardest choice here.  On the one hand, strictly derived fields are safe and don’t undermine the invariants; on the other, without more help from the language or runtime, we can’t enforce that additional fields are actually derived, *and* it will be ultra-super-duper-tempting to make them not so.  (I don’t see remotely as much temptation to implement maliciously nonconformant accessors or equals methods.)  If we allowed additional fields, we would surely have to lock down equals/hashCode.
> 
> I still want to understand what the scenario we're worried about here is. Whether the value is computed later using a "lazy fields" feature or eagerly in the constructor, only the record's state is in scope, and sure, people can shoot themselves in the foot by calling out to some static method and getting some result not determined by the parameters, but why is this worth worrying about? Do you have an example that's both dangerous and tempting? (Sorry if you've said it before.)
> 
>  


If we did allow them, the next thing people (Alan already did, and you made this same comment in an earlier round) would ask is whether they can be mutable — so that derived fields can be lazily derived,  Now, records are a combination of a “true record" plus an unconstrained bag of mutable state.  And what do you think the chances are that this state won’t make it into equals/hashCode semantics?   Now, we’ve completely lost our grasp on the semantic constraint — that a record is “just” its state.  We could try to put the toothpaste back in the tube by clamping down on the ability to override equals/hashCode, but now the previous example rears its head again.  

Worse, it does a lot of damage to the mental model of what records are for. We know they’re not about writing a class with fewer lines of code (though that’s an advantage), they’re about transparent carriers for a defined unit of state.  But, if users routinely see records in the wild with lots of extra state stapled to the side, maybe even affecting equals/hashCode, this design center is going to be harder to see (this ultimately leads to a feedback loop, where users who can’t understand what the feature is for will demand more features that are out of line with its design center, further obscuring the design center.)  

As I said to Alan, uncomfortable tradeoffs indeed.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190308/be08c5ba/attachment.html>