Annoying name collision

I semi-regularly encounter the issue of name collisions between a struct and a trait. I don't like renaming one of them to keep track of the underlying "type", because it's redundant. I.e.:

struct Node { }

trait NodeTrait { }

I could stick one of them in a separate module to give it its own namespace.

But I'm wondering if there's any defacto standard way to do this? What's your preference, and why? (Let's for the sake of the argument say that yes, both are indeed called Node and Node, and there isn't any more appropriate name for them).

Someone suggested calling traits "behaviors", like NodeBehavior -- but to me this is essentially the same as calling it NodeTrait.

Not an important topic, but I'm curious if the community has settled on some common way to resolve these types of collisions? (I strive to be idiomatic; when in Rome, etc).

1 Like

From what you have given there I have no idea what either of these are. You have a thing called Node which presumably has data and methods of it's own. And a trait called NodeTrait which presumably adds more methods.

Well, it that case it does not make any sense to me for both of them to be called Node I mean you must have added something to a Node buy giving it a trait. The name of the trait should, I suspect, indicate what that extra 'something' is.

For example, I am an instance of human, I have all kind of properties like mass, volume, height, gender etc.

Of course if you want to send me a package you need to know my address. That addressability is not a property intrinsic to my being human, but a useful trait for me to have.

1 Like

This collision happens sometimes when I want to have two representations of the same data. One that is used during construction, and one the final representation. The first one is responsible for compile-time validation and costly runtime validation (but only done at process initialization), the second one is the for performance during "regular runtime".

I've been working on a two libraries lately that have this type of layout and there are reasons for them to have the same name (less confusing to developer using the libraries), but since it is after all a name collision so I need to find a non-annoying way to work around that.

I guess this isn't as common of a problem as I thought it was. I'll simply invent my own convention and stick to it, and change it if someone yells at me once I release it. :slight_smile:

Name collisions are inherently confusing to downstream developers. I would tend to name them something related but distinct, perhaps trait Node, struct NodeBuilder, and struct CompiledNode.

4 Likes