Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support both "library" and "module" namespacing #688

Open
Manishearth opened this issue Sep 13, 2024 · 0 comments
Open

Support both "library" and "module" namespacing #688

Manishearth opened this issue Sep 13, 2024 · 0 comments
Labels
A-attributes Area: configurability via attributes enhancement New feature or request

Comments

@Manishearth
Copy link
Contributor

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 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>".

@Manishearth Manishearth added enhancement New feature or request A-attributes Area: configurability via attributes labels Sep 13, 2024
@Manishearth Manishearth added this to the ICU4X 2.0 nice-to-haves milestone Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: configurability via attributes enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant