bearophile wrote:
Leandro Lucarella:
grauzone:
- the current import semantics should be redone such that "import
a.b.c.d;" works like "import d = a.b.c.d;", and add a new syntax like
"import a.b.c.d.*;" to get the current behavior
Shouldn't be static import a.b.c.d;? It's a little odd to get imported
just the last part. I'm not convinced though.
davidl:
Yes, the package does not offer us enough functionalities. However,
only saying "I have discussed/talked/stated/complained something XXX
times" does nothing good to the current state. Contrarily, I prefer
one list the reasons of why current one is broken and corresponding
sophisticated solutions.
I can answer both, adding a small change from what I have said last time :-)
import foo;
Imports in the current namespace the "foo" module name.
import foo: *;
Imports in the current namespace all the names inside foo, but not the "foo"
module name itself.
import foo: bar, baz;
Imports in the current namespace the "bar" and "baz" names, but not the "foo"
module name.
bar and baz can be anything, packages too.
It's a shame that I never took a combinatorics course. This whole issue
looks like a homework assignment from the second semester:
"(0) Enumerate the set of use cases for importing source code modules.
(1) Outline the minimum amount of directed graphs that covers all these
use cases. (2) Either prove that circular graphs are unavoidable, or
show how they can be avoided with a standard transform." etc.
At any rate, we should totally avoid discussing syntax *until* we have
come up with the requirements that are needed. There's no use in
cluttering the discussion with syntax while we aren't clear on exactly
what is needed (and what is not needed).
Oh, and for clarity, we probably should define Circular as a mutual or
an a->b->c->a dependency. The case a->b->d + a->c->d is, IMHO not
Circular. It should have some other name, to avoid confusion.
As for Friend modules, these might arise when a library includes (for
the sake of practicality) sub-modules. Can the library programmer be
required to refactor the Friend needs to a new module that the other two
both import?
A library with a main and sub modules, where the sub modules may be
individually imported (as in std.c.whatever), seems to impy that
importing the sub module does not necessitate making the main module
visible. It seems to merely be a path component in finding the sub
module. Probably this should be the norm.
(Just scratching the top of the iceberg here.)
