You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently namespacing support in Diplomat is primarily "library" namespacing: it is for cases like C++ where the code is otherwise polluting a global namespace. Most languages don't have this problem, everything is already "namespaced" under the package you imported it as.
Users (like ICU4X) applying namespacing to their code for global-ns-pollution reasons will only want that in C++. Nobody wants the JS API to look like import icu4x.icu4x.DateTimeFormatter, and so far we've avoided adding namespacing to the other backends because of this.
There is a second type of namespacing that we do not really support, which is for API organization (and handling name clashes).
We should support these as separate things, library_namespace vs module or something. "module" namespaces can be nested (#103), and would likely be (eventually) supported by all backends, whereas library_namespace would only be used by C++. We may also move this over to a config.
In C++ this would just tack on to the existing namespace stuff, but other languages would use their code organization tools to handle this.
ICU4X may need this if ICU4X FFI decides to do things like "export a large number of types corresponding to all or many instantiations of types like datetime::Formatter<C, FS>".
The text was updated successfully, but these errors were encountered:
Previously: #589
Currently namespacing support in Diplomat is primarily "library" namespacing: it is for cases like C++ where the code is otherwise polluting a global namespace. Most languages don't have this problem, everything is already "namespaced" under the package you imported it as.
Users (like ICU4X) applying namespacing to their code for global-ns-pollution reasons will only want that in C++. Nobody wants the JS API to look like
import icu4x.icu4x.DateTimeFormatter
, and so far we've avoided adding namespacing to the other backends because of this.There is a second type of namespacing that we do not really support, which is for API organization (and handling name clashes).
We should support these as separate things,
library_namespace
vsmodule
or something. "module" namespaces can be nested (#103), and would likely be (eventually) supported by all backends, whereaslibrary_namespace
would only be used by C++. We may also move this over to a config.In C++ this would just tack on to the existing namespace stuff, but other languages would use their code organization tools to handle this.
ICU4X may need this if ICU4X FFI decides to do things like "export a large number of types corresponding to all or many instantiations of types like
datetime::Formatter<C, FS>
".The text was updated successfully, but these errors were encountered: