Method naming conflicts even if method signature does not?

Yes, you would need to take on that as a dependency…if it doesn’t fit well with the package, or you think it is too heavy, then it isn’t a good idea. Your best bet is to rename your function and just move on.

The reasons for this behavior are complicated and either obvious or perplexing - depending on what previous languages you come from. Function name conflict: ADL / function merging? gives plenty of background on different worldviews here. This is a nontrivial language design question.

Single dispatch doesn’t have this issue since there is no chance for conflicting concepts. That is myobj.weights() knows to look in the namespace associated with the type of myobj. C++ does it with overloaded functions and different types, but the rules are crazy and it doesn’t work with dynamic dispatching. Lisp people find the Julia behavior obvious.

But what you are describing is not type piracy (if it is only your type) but rather “punning”. Julia does not have a convenient way to have multiple non-overlwpping concepts active at the same time. While having overlapping concepts for the same function name is obviously a terrible idea, it is more innocuous if there is no overlap in the types involved. You need to coordinate on extending the same function manually, and being careful not to actually engage in any type piracy.

…or just rename your function and move on. Which is what most people do. Those who create packages first get the pick of the litter in nice function names.

1 Like