From recent feedback and from existing understanding, it is recognized that global is not an ideal package name.
Names such as kv, global and standard can easily overlap with other packages in the language ecosystem.
Consider giving them more unique names to improve developer productivity. Users shouldn鈥檛 stress about importing the name package by constantly checking the import paths or shouldn鈥檛 have to rename imports because of an overlap.
Based on the function of this package it seems like an appropriate package, but it would be ideal if we can brainstorm improved names.
I think global is a fine package name and I have yet to experience any conflicts with other packages.
I was refactoring some code and noticed that we've moved ErrorHandler to the root of the repository. In the sense that a "root" is global, it might make sense to put everything from the global package into the root of the repository. Then we'd read otel.SetMeterProvider() which sounds good, as opposed to global.SetMeterProvider().
I was refactoring some code and noticed that we've moved ErrorHandler to the root of the repository. In the sense that a "root" is global, it might make sense to put everything from the global package into the root of the repository. Then we'd read
otel.SetMeterProvider()which sounds good, as opposed toglobal.SetMeterProvider().
I like this approach. :+1:
Looking at this migration our global getter functions (i.e. MeterProvider, TracerProvider, and ErrorHandler) will all clash with their types. Looking at rename options for the getters:
Get*Default*, also switch setter to SetDefault*Global*, also switch setter to SetGlobal*Leaning towards (1)
Looking at this migration our global getter functions (i.e.
MeterProvider,TracerProvider, andErrorHandler) will all clash with their types. Looking at rename options for the getters:
Get*Default*, also switch setter toSetDefault*Global*, also switch setter toSetGlobal*Leaning towards (1)
+1 for option (1).
Looking into flattening this out last week and found the initial dependency cycle that likely split the package in the first case.
And also now,
These import cycles appear to be artifacts of the tight coupling of these packages. A good indicator that they need to be refactored, but it will require a bit more work than just moving this.
Most helpful comment
I like this approach. :+1: