<div dir="ltr"><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">Hello Ron,</div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">Thank you for your response!<br></div><div style="font-family:monospace" class="gmail_default"><br>> I don’t see a lack of representability. Java’s records<br>> can represent tuples — the thing they are meant to<br>> represent.<br><br>Apologies, I was not clear here. My question to you is actually, do you see a problem with the fact that records cannot represent a circular reference to themselves?<br><br>According to the definitions I cited earlier, tuples/product types have circular references in their domain of possible values, and therefore, we do have a lack of representability if I model my data as nodes, and not edges. The fact that you can sidestep that by modelling it as edges does not change the fact that you do indeed have a gap of representability.<br><br>And to be clear, this question rises above State Transition Diagrams and just talks about circular references alone.<br><br>> and if you want to represent a graph in a more<br>> OOPy/pointery way, i.e. not with tuples, use classes that<br>> aren’t tuples, which are also representable in Java (and<br>> you can also make them immutable if you like).<br><br>Are you saying you can accomplish this without indirection, as in without a Map lookup or something equivalent? If so, please demonstrate.<br><br>> To represent a potentially cyclic graph with tuples you<br>> can use the ordinary representation of edges<br><br>I understand your point, but this requires me to apply an ill fitting model because the language is unable to map the one I actually need.<br><br>I am modeling control flow. The question that I am constantly asking is "What are my next possible steps from this current node?" Rather than having the node store that information directly, you are telling me to create a set of edges and simply perform a lookup on this set, filtering down to the ones that start/end (assuming bidirectional) with my current node so that I can figure out what my next option is. Do you see what I mean when I say that this ia a bad fit?<br><br>Yes, technically, that works, but this is even worse in the department of indirection. I didn't want to avoid indirection because indirection is in and of itself bad. I wanted to avoid indirection so that my model would have as little intellectual and data overhead as possible. I wanted to be able to answer my question as directly as possible so that I can reason about my problem as easily as possible. Your solution goes completely in the opposite direction of that and adds so much overhead that I would sooner choose the workarounds I mentioned originally.<br><br>And I'm sure that your strategy would be more useful in a weighted graph or something, but hopefully you see where I am coming from here?</div><div style="font-family:monospace" class="gmail_default"><br></div><div style="font-family:monospace" class="gmail_default">Thank you for your time and insight!</div><div style="font-family:monospace" class="gmail_default">David Alayachew<br></div></div>