Closed chad-klumb closed 4 years ago
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?
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.
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
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
references statnet/network#14
we should change the travis pointer to statnet/network@master once statnet/network#14 is merged