updates for compatibility with new network generics

[chad-klumb]

references statnet/network#14

we should change the travis pointer to statnet/network@master once statnet/network#14 is merged

[skyebend]

I'm assuming it is just quiet to the warnings to make it play nicely with changes to make network::get.network.attribute a generic? I've been reluctant to do this in the past because we don't have an active class, and unfortunately are using the . in the function names in a non-standard way. i.e. we use the .active suffix on functions to indicate that the network argument should be treated dynamically, rather than as a static network. ... but if the tests didn't fail, I'm guessing the dispatch must still work ok, its just a confusing model? If we call get.vertex.attribute() on a networkDynamic object (which I think should have class c('network','networkDynamic')) will it ever try to dispatch to get.vertex.attribute.networkDynamic() by mistake and not find it?

[chad-klumb]

It should dispatch to the first suitable method it finds, starting at the first class name and going down the list (eventually looking for a .default method if nothing is found matching any of the class names). So, if get.vertex.attribute.network is defined (which it is, in the version of network in the PR), it should dispatch to that. Only if get.vertex.attribute.networkDynamic were defined (which it isn't, AFAIK) and networkDynamic came first in the class vector would it dispatch to that instead.

[skyebend]

realized that this should also have a date and version bump in DESCRIPTION, and set to require >= whatever network version number will have refactoring of generics

[chad-klumb]

realized that this should also have a date and version bump in DESCRIPTION, and set to require >= whatever network version number will have refactoring of generics

done

[skyebend]

I think this is ready to merge ... whenever network gets to cran. thanks for sorting this out!