-1 from me, for the same reasons we moved away from Framework Settings as
extension methods on a central "Settings" class.
I think the reason was not only this.��
In most cases settings affect class variables which provide default values for instances. So it is just suitable to define settings in same place where state is defined.��
Also it not breaks encapsulation.
And in case of FileLocator it will not access anybody state. It is about constant file paths.
��
Keep "globals" related to a package local to the package where they are
used.
I just want practical solution. Now there are no tools to browse what files are used by applications. And simple convention could be good enough.