The types of your nodes probably don't have much to do with any algorithms you may be writing. Consider your algorithms as functions which act on an interface. Keep your graph data within a type which adheres to that interface. Then you only have to duplicate the type and not the algorithms, and you can easily create new types which the algorithms can use.
Even if you stuff the algorithms into the same type you have your data in (like most generic languages seem to encourage you to do), you still only have to type-cast/type-switch on getters and callbacks. And the only major missing requirement I can think of is that your nodes aren't guaranteed to be of homogeneous types (and you can hack that with a callback if you want).
> "The types of your nodes probably don't have much to do with any algorithms you may be writing."
Which is precisely why he wants generic types.
> "Consider your algorithms as functions which act on an interface."
How would he write a function that explicitly expects a graph whose nodes contain ints, and not, say, strings? What kind of interface would that function act upon?
> "you still only have to type-cast/type-switch on getters and callbacks."
Even if you stuff the algorithms into the same type you have your data in (like most generic languages seem to encourage you to do), you still only have to type-cast/type-switch on getters and callbacks. And the only major missing requirement I can think of is that your nodes aren't guaranteed to be of homogeneous types (and you can hack that with a callback if you want).