Here are several answers:
If the Cell objects are not changed (mutated), then it is ok to have the lists c and b both share structure, as in your example, because the outcome is (roughly speaking) invisible to the client code.
But if the client code were mutating the Cell objects, then there may be design rationale for not sharing structure -- which could mean always copying lists before splicing them.
But there is an interesting question here -- suppose the payload of a Cell pointed to a mutable object (say a StringBuffer rather than a String). Would you copy that mutable object too?
And there is another interesting question: If we are worried about how much space is used for lists, and we had assurance that a list in your example was NOT used at all after the call to append, then the last cell of that list could be mutated to point to the list referenced by b, and no new Cells would have to be constructed.
The bottom line is that there are many policy options, and correspondingly many implementation options, and and therefore many opportunities for confusion regarding policy for copying, mutating, and the like.
The best way to think about this is to consider the needs of the client code: Will there be mutating? Where and when will it happen? A careful analysis will determine which representation of lists (including null-terminated lists) will work best. |