Should we standardize the value of the module label?

[emschwartz]

We initially added the module label to help differentiate between metrics for functions with the same name defined in different modules. We specifically wanted to avoid the footgun of having those different functions' metrics getting merged when you don't expect them to be.

There might be other use cases for this label, such as graphing all of the functions that are part of a certain module.

The question is whether we should attempt to standardize the value of this label across programming language implementations. Currently, the Rust implementation uses the module path syntax crate::module::submodule while TypeScript uses the file path from the project root project/path/to/file.ts.

If we were going to standardize on a specific path type, we would probably need to do it based on the file path, because that is the only thing that we know is consistent across languages.

[hatchan]

I don't think we can make this generic using file paths, for example you can have multiple modules in the same same file, all with overlapping functions names in there.

I think it make sense to leave it up to the implementation language to determine the best namespacing that makes sense for the language. So with rust you'd have something like $crate::module or $crate::module::Struct, and in typescript something like the path could make sense. We could add another label, or a prefix to the module, to indicate which language was used and thus have even less change of overlap.

I think it would be good to define module as a container in which the function is going to be unique. Then the module + function will always be unique. We can rename the label name from module to be more generic.

[emschwartz]

Fair point. Works for me to keep it as is and just specify that, as you say, module + function should be unique