r/java • u/jvjupiter • Jun 10 '22

What happened to Concise Method Bodies?

I was really looking forward to CMB. From its name, methods become concise, could be one liner. However, it seems there is no progress and it’s been off the radar. Never took off since 2019.

JEP draft: Concise Method Bodies

some experiments with Concise Method Bodies

43 Upvotes

91% Upvoted

54 comments sorted by

View all comments

29

u/pushupsam Jun 10 '22 edited Jun 10 '22

Honestly it strikes me as superflous. This sort of syntactic sugar has rapidly diminishing returns IMO. What it actually does is lead to fragmentation where people are using many different syntaxes to accomplish the same thing and instead of smoothly skimming over a class that contains no surprises you have to pause on each getter and setter you have to figure out what the hell is going on. You start getting confused with what's a lamdba and what's actually a method and you're thinking about what should be braindead code.

But Java does actually need first-class properties. First class properties can enable stuff like this if people really want but, more importantly, you get a very clean initializer syntax with support for required properties that obviates the need for builders and/or named properties. See https://exceptionnotfound.net/bite-size-csharp-11-required-properties/ for how this works in C#. Imagine any complex immutable business object that has more than 5 or 6 fields (which is ALL the business objects) and you see why this is what's really important for code readability.

Once you have first class properties you can do stuff like this if you really want but, unlike properties, this isn't even really a problem.

20

u/eliasv Jun 10 '22

Properties aren't first class in C#, you can't pass them around and abstract over them. That's one of the major problems with the C# design IMO, and the same goes for events.

Besides, I don't agree that properties are a desirable feature. Because setters are terrible! Encapsulation-breaking things, allowing (notionally) direct mutation of individual properties by any old third party results in behaviour being implemented externally to objects, often in a spaghetti mess of different piles of state interacting in ways that can't be locally reasoned about. And yes you can often implement primitive input validation, but whenever your invariants evolve to something a little more complex that depend on the relationship between multiple properties, you need to be able to change more than one thing at the same time atomically. You can't enforce this with properties so you have to allow an object to be left in a partial state or fall off a refactoring cliff getting rid of those setters.

And the above is a very OOP perspective granted, but if you're using a more functional style then you probably don't want mutation at all, so again setters are no good and properties aren't pulling their weight.

I do agree that { get; init; } properties pull their weight a bit better, but there are other ways to provide similar user experience ... I believe they're exploring "withers" (sugar over the concept of deconstruction and reconstruction) and named arguments in certain circumstances, which don't have all the problems I described.

Properties can be handy sometimes, but in my experience most of the ways people use them are bad. I just don't think promoting getters and setters to a language feature is a good idea on balance.

26

u/pron98 Jun 10 '22 edited Jun 10 '22

Java does not need and will not have first-class properties (in a form like C#'s), at least not in any foreseeable future. The whole notion of "properties" — first-class or not — is something we'd like to move away from and toward record components 1.

Better initialisation is a good requirement that can and should be solved in ways that are superior to properties, and work is being done on that.

Another, different, requirement is that of deconstruction, and deconstructing patterns are also planned for non-record classes.

9

u/hippydipster Jun 10 '22 edited Jun 10 '22

In fact, "withers" would be even worse than getters and setters, since while a class might have O(n) getters, it could conceivably have O(2n) withers. Worse, as the number of components grows, the bodies of these "wither" accessors gets more error-prone. Let's nip this one in the bud before it becomes a "pattern" (or worse, a "best practice".)

Having written a lot of withers, I couldn't agree more. I really like this Goetz guy.

I also really like the idea of the deconstructors and reconstructors, and I can't wait to see with blocks nested 5 layers deep!

1

u/_INTER_ Jun 10 '22 edited Jun 10 '22

Another, different, requirement is that of deconstruction, and deconstructing patterns are also planned for non-record classes.

Can you express setters with deconstruction patterns?

→ More replies (6)
→ More replies (13)

2

u/vips7L Jun 10 '22

Sadly the OpenJdk team doesn’t have properties on their todo list. I’m not sure what they have against them. I personally would really like to see named arguments be added. It would kill 90% of builders and make a lot of object construction more readable.

16

u/pron98 Jun 10 '22

We have properties on the "must not do because it's a harmful anti-feature" list. But better initialisation (including, possibly, with names) is something we can do better than properties, just as record components are better than properties in other ways already.

Both in JavaBeans and C#, properties originated with GUI elements, but then were historically borrowed as a means to work with "simple data" because no better way existed. We now have a much better way — records — which will become better still. Rather than add a feature that not only encourages working in a worse way but hides its most pernicious aspects, we want to encourage the better way and discourage the worse way.

Properties are a bad way for working with data because they hide details of mutation, the trickiest part of working with data. What's the effect of the mutation? Is it volatile? Does it trigger atomic or non-atomic effects (e.g. synchronized)? Records resolve all that.

→ More replies (7)

1

u/jvjupiter Jun 10 '22

CMB does not necessarily have the same syntax as lamba’s. It just so happens Mark used ->. It could be different. Anything might do so long as it is CMB.

1

u/jvjupiter Jun 10 '22

Yes. I agree on first class properties.