Thoughts on opt-in mutability?

[Red IO]

One idea could be to make the class declaration special. In well structured
classes all fields should live at the top so having a class modifier like
"immutable" would be rather obvious even with lots of fields. Also rather a
field declared at line 20 and used in line 650 is mutable already requires
scrolling to the top.

On that note the editor/ide is a more often used indicator for mutablity of
fields by having color or styling differences in the variable name. (I know
relying on tooling to make things clear is not preferable but it's kinda
already this way)

An example class would look similar to this :

public immutable class Test {
private int field1;
private int field2;
private int field3;
private int field4;
private int field5;
private int field6;
private int field7;
private int field8;
private mutable int field9;
private mutable int field10;
}

Rather to combine default final and default private is another discussion.

A counter argument would be that allowing for any combination of defaults
would result in a keyword explosion:
immutable
mutable
closed (wip to make a class private default)
package-private

Just to allow inverting the defaults.

Also c# already has this for immutable fields. They have the readonly
keyword which is equivalent to final on fields in java but it also works on
the class making every field readonly. The problem with that approach in
java is that we already used final on classes to block inheritance.

Maybe we could instead drop the inversion (package-private and mutable) and
make it a 1 way decision like in records. But then the question would be
why not just use a record.

That are my thoughts on this topic. As one might have heard out I'm
undecided on the topic.

Great regards
RedIODev

On Thu, Jan 18, 2024, 17:56 Brian Goetz <brian.goetz at oracle.com> wrote:

> So, you provide several good arguments here for "Java picked a bad default
> with respect to mutability."  (It is in good company; Java picked many bad
> defaults, such as package visibility rather than private, classes being
> extensible rather than closed, etc.)  Let's just take it as given that
> non-final is an imperfect default for fields.
>
> Which brings us to the next question: "now that we realize the default is
> bad, should we change it?"  This is a much harder question, because it
> involves the reality of 10M developers and billions of lines of code.
>
> One bit of prior art here that might be relevant (and the experiment is
> still playing out) is C#'s flipping of the nullability default on a
> per-module basis (with injecting checking at the boundaries.)  This was a
> bold experiment and we are interested in seeing the results.
>
> The problem with trying to fix the mistakes of the past is that in most
> cases, you are just creating a fork and forcing users to deal with both
> branches.  If we had a directive:
>
>     class X {
>         #pragma default-final
>
>         ...
>     }
>
> then now users have to keep track (possibly on a per-file basis) of where
> "int x" means final or mutable.  This is adding cognitive load to all
> users, since almost no Java developer has the luxury of controlling 100% of
> the code they deal with.
>
> A one line distillation of the above is perhaps: "Immutability is common
> enough to consider a fast path at source level; the current slow path has
> negative consequences for cognition and devx."
>
>
> Valid, but what this misses is: "having to constantly reason about whether
> line #656 of Moo.java is on the fast path or the slow path has even higher
> cognitive load."
>
>
> On 1/17/2024 10:20 PM, Subra V wrote:
>
> Hello Project Amber team,
>
> What are the current thoughts on providing source level mechanisms for
> opting-in to mutability rather than the current opt-out? For example, a
> notion of immutable class (not a record) can obviate specifying "private
> final" for fields. Opt-in mutability would perhaps also jive with two
> recent themes in language evolution: 1. Functional style 2. More cognition,
> less ceremony (switch statement, pattern matching to name a few).
>
> If there's prior relevant material, I'd appreciate a pointer; Dr. Google
> hasn't uncovered anything of note.
>
> I realize that this question has red flags of "proposing a solution" to
> "my specific problem". So, let me clarify that (1) I only write because I
> believe there's a reasonable chance that opt-in mutability is of fairly
> broad interest. (2) I am not proposing obviating the need for 'private
> final' as a solution; instead, it is meant to be analogous to saying 'I
> want String interpolation', a 'solution' from which language designers
> carefully teased apart a general problem and solved it in the form of
> String Templates.
> ---
>
> I am certain language designers are aware of this (and plenty more), but
> in the interest of intellectual honesty, let me attempt to articulate
> problems with default-mutability from my default-immutable practice.
>
> 1. [Immutable style feels second class] Java has moved in a functional
> direction much to my (and most practitioner's?) pleasure. For the subset of
> folks who buy into this direction, Immutable classes are natural. Yet, they
> feel second class in that (1) notions of "private final" aren't relevant
> yet pollute (2) It requires extra work [making all fields final, binding
> them in constructor] compared to the default case of mutability
>
> 2. [Cognitive Cost of Ceremony] For non-record Immutable classes, I have
> to (1) Write 'private final X' and then add a constructor param and set
> `this.X = X` in the constructor. (2) Read and verify `private final` on
> every field to know that the class is immutable. Even though IDEs help, it
> breaks the flow of thought both when reading and writing
>
> 3. [Poor Prototyping Velocity] I often find the ceremony especially
> frustrating in early phases of design, especially when using immutable
> classes. Imagine I have 20 concepts/fields and I am attempting to organize
> them. A common occurrence is to realize 'ohh this field/method logically
> belongs to that other class; let me move it there' but it is a pretty big
> chore to do so (even with Intellij) given that immutability takes extra
> work to achieve. Such moves also come with further transitive ripple
> effects. All the busy work perhaps accounts for upwards of 30% of the
> initial few hours/days of design and more importantly, constantly
> interrupts thoughts. For contrast, if I just make every field public during
> the initial period, it'd probably be a better experience, but then I need a
> magic wand to make them all immutable after the design settles down.
>
> A one line distillation of the above is perhaps: "Immutability is common
> enough to consider a fast path at source level; the current slow path has
> negative consequences for cognition and devx."
>
> Appreciate thoughts.
>
> Thank you,
> Subrahmanyam
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240118/f18bd737/attachment.htm>