make vertex/edge/network attribute getters/setters generic?

[chad-klumb]

A small piece of this has already been done for vertex attribute getters. Vertex attribute setters and everything for edge/network attributes have yet to be made generic. Some of this will "break" networkDynamic in the same way PR #14 did, and we should be able to fix it in the same way statnet/networkDynamic#2 did.

These generics will support continued development of networkLites and other network-related data structures.

@skyebend @CarterButts @krivit Any objections?

[skyebend]

Isn't it trickier for the setters, because user need to be able to call both a 'static' and 'dynamic' version of the setter on the object depending not on the class of the object but according to the intent of the user? (sorry it is a while since I've had my head in this) Can you outline what calls would look like for each case?

[chad-klumb]

By "dynamic" setters do you mean the activate.*.attribute functions in networkDynamic? I do not think it would be necessary to change those; networkLites are not really dynamic objects (beyond optionally toting around time and lasttoggle network attributes), so I was planning on only modifying the network package setters (like set.vertex.attribute). Are those what you would call "static" in this case?

[skyebend]

ok, I think I had it backwards, it was the get (which you already implemented) that has to handle both classes, as you say the 'setter' for dynamic attribute is activate so no collision with generics.

Sounds like a good idea to me! we may to need to slightly tweak some tutorials

[chad-klumb]

This should be dealt with by PR #30. get/set/list/delete are now generics for vertex/edge/network attributes. statnet/networkDynamic#7 provides related updates for networkDynamic.