WeakReference for referencing Nodes/Relations?

[Syndesi]

Nodes can have many relations and relations have two nodes. Cyclic references like "node A has relation B, which starts at node A, which has relation B, ..." can be a huge problem for the garbage collector.
Idea: Instead of referencing the nodes/relations directly, they could be referenced through WeakReferences. Once one of the referenced objects is no longer used, it gets automatically removed by the garbage collector.

New property types

• NodeReference: A class which contains a single WeakReference. Makes sure that only nodes can be referenced.
  Provides a way to access the referenced node.
  Will be used inside the Relation-type for start- & end-node reference.
• RelationReference: A class which contains a single WeakReference. Makes sure that only relations can be referenced.
  Provides a way to access the referenced relation.
• RelationReferenceStorage: A class extending SplObjectStorage, which can store multiple RelationReference.
  Will be used inside the Node-type for referencing all relations.

Possible problems

• Nodes and relations require a non-weak-reference to be not deleted, otherwise the missing references can create logic problems.
  Not a problem in this library, because this should be handled in an entity manager (part of another, currently not existing library).
  Though the documentation should contain explicit warnings.

Notes

• There is another type called WeakMap, which is in some parts similar to SplObjectStorage. Though it is a) final, therefore can not be extended. And b) it does not have a getHash() method like SplObjectStorage.
• Doctrine had a similar discussion before, though without any results as far as I can tell.

[Syndesi]

I'm going with the following setup:

• Nodes contain a property called WeakRelationStorage
• WeakRelationStorage is an instance of SplObjectInterface, containing WeakRelation objects.
• WeakRelation objects are custom classes which contain a weak reference to a single relation.
• Relations use nodes directly in their data model, because the start and end node are identifying properties.