ImmutableGraph should have ImmutableSet of nodes and edges

Please consider overriding ImmutableGraph#nodes() so that it returns an ImmutableSet, to make the contract clearer. Similarly for edges(). (Somewhat related to #3034.)

[oliviercailloux]

To summarize the discussion so far, I think that we agree that the feature discussed here is desirable, but intuition varies on whether this is implementable without breaking the contract of Immutable* structures, and without introducing huge supplementary complexity in the code, or other important drawbacks.

I understand that you can’t commit to accept PRs that implement this feature without knowing the associated liabilities, especially if you fear they will be large. And knowing the liabilities in advance is hard.

It seems to me that the current discussion, where I try to develop my intuition that it is in fact possible with low costs, is becoming quite technical and unefficient, because it can’t be kept to a high level discussion (details matter) and because checking my claims would require more than a short textual description.

May I suggest that I start trying to implement this feature with my student, and see where this leads us? Perhaps we will realize this is indeed impossible. Perhaps we will find a way.

The original goal of my proposal was only to ensure that the task is not a priori impossible, because the Guava team would be opposed to this feature, for some reason independent of the quality of the submitted code. Re-reading the discussion so far, it seems to me that this is not your state of mind. (And I thank you again for the insights.)

If you can confirm some a priori willingness to review relevant PRs, assuming we can find a reasonable implementation for this feature, we’d be relieved to know that the work can at least be useful. I repeat that I do not expect, of course, an a priori commitment to accept any PRs.

[jrtom]

@oliviercailloux Speaking only for myself (as the owner of the common.graph piece of Guava) I think that what you want to achieve here is overall desireable, and I am willing in principle to look at external submissions like this, but in practice I have two concerns:

(1) Additional implementation complexity has a real cost to those responsible for maintaining the system. I’d prefer not to get into a state in which I don’t understand how the code I’m responsible for works. 😃

(2) I am very overloaded right now with other work; I actually have several different common.graph-related projects that I’d like to move forward but haven’t had the time to pursue any of them. So I’m hesitant to provide any guarantees that I personally could review a PR of this anticipated complexity in a reasonable timeframe (not sure what you might be expecting here).

If @lowasser or someone else from Guava is willing to devote some time to reviewing your submission, that might be an option, but I can’t speak for anyone else.

(Ideally at some point there will be more people on our side to work on common.graph stuff so that I’ll be less of a bottleneck.)