[External] : Re: Question about circular references

[David Alayachew]

Hello Ron,

Thank you for your response!

> You’re repeating the same thing of reaching for a feature
> designed not for your use case. Records are immutable,
> but not everything that’s immutable is a record.
> Similarly, final fields do describe immutable data in
> Java, but not everything that’s immutable can or should
> be final.

Admittedly, I should have been more clear. But my point was, I don't
particularly care if I use final fields either.

Again, the only constraints I had were these.

* Immutable
* Nodes DIRECTLY referencing other Nodes -- no indirection, no id or map
lookup -- pure direct references
* Permit circular references

Through all the responses I have been given, none of them have been able to
hit all 3. I only started with records because the definition provided
seemed to be a good fit for my problem. You seem to disagree, and I
addressed your disagreements, but your response here doesn't attempt to
retort on that. It only focuses on me talking about final fields, since I
am fine using them instead, if need be.

> Final fields are a Java feature that guarantees some
> things about initialisation order and other
> initialisation-related guarantees, but you can, in this
> case, think of it as the feature you use when you need to
> ensure there are no cycles. So what you’re asking is, how
> do I use Java’s feature for excluding cycles to admit
> cycles? The answer is: you don’t.

To be honest, I actually question this logic too -- about thinking of final
as not permitting cycles here. And even if that holds, I'm pretty sure that
further discussion will lead to me criticizing that too, eventually.

But regardless, you are declaring this out of the blue. Where are you
coming from when you say this? What backs this statement up? I have come to
you with widely accepted definitions. If you are going to say that final
fields, in this instance, don't permit cycles, I need you to explain how
and why, not just claim that they do.

> A common OOP pattern is to have a mutable builder than
> then uses private access to create immutable objects
> (don’t expose mutating methods). They can still be simple
> data carriers, and if and when we have deconstruction
> patterns for non-record classes they can make use of
> pattern matching, too.

By all means, I am not picky. Can you show me what this would look like
though? I can understand how you would achieve immutability doing this, but
not the directness constraint I am talking about above.

> The language supports this just fine. It just doesn’t
> support it with the feature designed for tuples, because
> what you want isn’t a tuple, and it doesn’t support it
> with a feature designed to enforce a particular
> initialisation behaviour when it’s not the behaviour you
> want. Yes, you can rely on the fact that final fields are
> tied to constructors and so do some clever initialisation
> in the constructor, but my general point is that you’re
> reaching for features that were designed for other uses.

And I addressed why I thought your logic is flawed, but you have not
responded to that. Instead, you are talking about final fields. By all
means, I'd like to see how we can address this with something that isn't
final fields or records, but I've yet to see that.

Thank you for your time and insight!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230704/97cfa357/attachment-0001.htm>