Avoiding name clashes when libraries evolve

Dealing with name clashes

If a new Alore version introduces new definitions in a module, they could cause a name clash with an identically-named definition in a user program.

Python has from m import x, y, ... syntax to only import a subset of identifiers defined in a module. This makes the import future-proof: additional identifiers to the module do not break the module that does the import, even if the names would clash with other modules.

Alore has only import m, and if the file accesses global definitions without a module prefix, name clashes are possible if future versions of x introduce new names. However, this is still much better than the form from module import * in Python, since the parser can always report these ambiguous references precisely, but in Python name clashes cause silent overwrites.

Here is a way of dealing with name clashes in Alore, which seems to be good:

• Support both import m and from m import x, y, ....
• Make std module names have lower precedence than other modules. This way a std module update cannot cause a name clash. Otherwise additions to std can be problematic since it's always imported.
• Support a checker option that reports a warning if all of the following conditions are true in a file:
  • The file imports two or more modules using syntax import m. (And the modules are from different sources that do not co-operate in avoiding name clashes. E.g. one of them is a standard library / external library module and another is part of the program. These imports could cause a future name clash that is beyond the control of the developer.)
  • An access to one of the modules mentioned above does not use a module prefix, i.e. form x instead of m::x. This kind of reference can cause a future name clash when a module is upgraded to a new version. Qualified references are safe.
• The above allows using unqualified names and the form import m, but only when it's future-proof. This gives a both convenience and maintainability.

Module names

Module names may clash as well. We could recommend that external library modules have two-component names of form vendor::mod. Similarly, programs should only use up to a few different top-level module prefixes, and to avoid generic top-level module components such as "model" or "domain".

Having Java-style deep name hierarchy is an unnecessary pain for most small-to-medium-sized projects.

Single-file modules without separate directory

It would be more convenient to have deeper module hierarchies if each new module component would not require an additional nested directory.

Maybe also support storing single-file modules without a separate directory, a bit like Python. For example, module foo could be stored in file foo.alo or in directory foo/. Module foo::bar could be stored in file foo/bar.alo or in directory foo/bar/. Files belonging to module foo would be distinguished from submodules by looking at the module header.

This would probably be cleaner than Python and offer most of the flexibility.