[External] : Re: Question about circular references

[Ron Pressler]

> On 4 Jul 2023, at 18:52, David Alayachew <davidalayachew at gmail.com> wrote:
> 
> 
> My entire point thus far has been acknowledging that, yes, these things are not representable, but then saying that they in fact should be. You have been retorting the entire time saying they are not representable and that's not a problem because of (what I perceive to be) circular logic. You have still not responded to those points I've made by the way.

I’m saying that sometimes you want to allow cycles — and Java has your back — and sometimes you want to know things about initialisation, which is why we have final.

> 
> whether it is through records or final fields or something else entirely, we are currently unable to represent cycles.

This is clearly not the case. Java classes easily represent cyclic data structures. The features to do that have been part of Java since day one.

> But that is a byproduct of the particular set of mechanics Java provided to create records and finality. At no point along the line was it said that final SHOULD NOT be able to represent circular references. And it is THAT that I am asking for evidence for.

That’s not how this works. If you want to add a feature to make *final* cyclic references possible it is you who need to show how that would solve a big problem for Java users, who can currently already represent cyclic data structuresl.

> We have more boilerplate than multiple other solutions combined, and even then, we have to go deep into indirection to EVENTUALLY construct a direct solution. It's the worst of both worlds while still checking all the boxes. Knowing that this is the actual solution to my problem makes me wish for another solution that much more.

But adding another Java feature to address every use case has downsides, too. What we care about isn’t the effort in a *particular* case but the effort integrated over *all* cases. We trade some slightly cumbersome code in few situations for a simpler language overall. However, if your primary concern is the need to write accessor methods, there is a “concise method declaration” feature on the table, but it’s low priority because there are bigger problems we need to tackle, first.

As I’ve said to others before, the best way to motivate a change in the language is to identify a BIG problem, i.e. one that is either very common or one that takes significant effort to get right with existing constructs.

We all run into problems that the language could help with, but unless it’s the same problem every time or it’s a very difficult problem, changing the language to address each of those problems creates its own problem.

— Ron