I had a case where I was mapping over a graph and assoc'ing a uuid onto each. This caused my directed graph to have lots of 'copies' in it, since each call to the mapping function resulted in a different value. The result is a graph with a 2 new nodes per edge.
At first, I thought that changing mapped-by might be wrong, since it's generally poor form to use state in map/filter/etc. However, I realized that none of the derived graph functions are lazy, they're all eager, so this probably fits in line with the existing design.
An alternative for me would be the ability to edit/update a node, with semantics similar to update-in or swap!. An example of that would be:
(update-node graph node #(assoc % :id (rand-int))).
I had a case where I was mapping over a graph and assoc'ing a uuid onto each. This caused my directed graph to have lots of 'copies' in it, since each call to the mapping function resulted in a different value. The result is a graph with a 2 new nodes per edge.
At first, I thought that changing
mapped-bymight be wrong, since it's generally poor form to use state in map/filter/etc. However, I realized that none of the derived graph functions are lazy, they're all eager, so this probably fits in line with the existing design.An alternative for me would be the ability to edit/update a node, with semantics similar to
update-inorswap!. An example of that would be:(update-node graph node #(assoc % :id (rand-int))).