i wrote a module which public imports other modules (to avoid importing 'em by hand, 'cause import lists depends on version()). then i imported this 'main' module with renaming: import zmod = my.module;

now i can't acces any identifiers from modules that my.module public imports and i forced to copy-paste the whole my.module public import section each time. little sampe:

module my.module;
public import other.module;
…

module mainprogram;
import my.module;

now i can access other.module symbols without qualifiers


and another case:
module mainprogram;
import zmod = my.module;

now i CAN'T access other.module symbols without qualifiers. the only way to access 'em is to use horrible 'zmod.other.module.symbol', which completely defeats my purposes for public imports in my.module.

can i use import renaming, but still access my.module public imports as if there was no renaming?

i don't want to fall back to struct/class namespace emulation hackery and i don't want to prepend all names in my.module with some prefix (and my.module have many widely-used names such as 'init', 'deinit', 'write', etc).

the question is: is such behaviour of 'import' intentional, or this is just bug and it will be fixed eventually?

On Monday, 28 April 2014 at 00:52:50 UTC, ketmar wrote:
> module my.module;
> public import other.module;
> …
>
> module mainprogram;
> import my.module;
>
> now i can access other.module symbols without qualifiers
>
>
> and another case:
> module mainprogram;
> import zmod = my.module;
>
> now i CAN'T access other.module symbols without qualifiers. the only way to access 'em is to use horrible 'zmod.other.module.symbol', which completely defeats my purposes for public imports in my.module.

`zmod.symbol` works, too.

> can i use import renaming, but still access my.module public imports as if there was no renaming?

I don't think so. The point of the renamed import is that you have to use the new name. If you want the new name to be optional, import the module twice:
    import my.module;
    import zmod = my.module;
This way both `symbol` and `zmod.symbol` work.

>
[...]
>
> the question is: is such behaviour of 'import' intentional, or this is just bug and it will be fixed eventually?

As far as I can see, everything works as intended.

On Monday, 28 April 2014 at 15:57:16 UTC, anonymous wrote:
> `zmod.symbol` works, too.
no, it's not. at least on latest GDC.

> I don't think so. The point of the renamed import is that you have to use the new name.
but i renamed only my.module, not others. nothing hints me that renaming is SO global. it's counterintuitive.

> If you want the new name to be optional
no, i don't. i don't want my.module symbols in global scope at all (it was static import in a fact, i relaxed it later).

> As far as I can see, everything works as intended.
so it's broken beyond any repair. so sad.

ketmar:

> so it's broken beyond any repair. so sad.

The current implementation of the module system has some problems, that are being worked on. If you think some part of the module system design is not good enough, then try to ask for an enhancement :-) No need to be sad.

Bye,
bearophile

On 04/29/14 11:57, ketmar via Digitalmars-d-learn wrote:
> On Monday, 28 April 2014 at 15:57:16 UTC, anonymous wrote:
>> `zmod.symbol` works, too.
> no, it's not. at least on latest GDC.

It certainly works here; if it didn't it would be a frontend problem.

>> I don't think so. The point of the renamed import is that you have to use the new name.
> but i renamed only my.module, not others. nothing hints me that renaming is SO global. it's counterintuitive.

You did not /rename/ it, you *named* it - so now you have to use that name to access all symbols inside the module, *including* any symbols imported from other modules.

>> If you want the new name to be optional
> no, i don't. i don't want my.module symbols in global scope at all (it was static import in a fact, i relaxed it later).

I'm not sure what you want to achieve, but one solution could be creating a module like:

   module mymodule;
   public import zmod = myzmodmodule;
   public import my.whatever1;
   version(blah)
      public import my.whatever2;

then:

   import mymodule;
   // ...

>> As far as I can see, everything works as intended.
> so it's broken beyond any repair. so sad.

The D module system has a lot of problems and certainly needs to be completely redesigned from scratch, but it does work as documented and can already handle simple cases as yours.

artur

Artur Skawina:

> The D module system has a lot of problems and certainly needs
> to be completely redesigned from scratch,

I don't think it will be redesigned from scratch (and if that happens I see no proof that the redesign will be better than the original design). So better to fix its major problems, as Kenji is trying to do :-)

Bye,
bearophile

On Tuesday, 29 April 2014 at 09:57:08 UTC, ketmar wrote:
> On Monday, 28 April 2014 at 15:57:16 UTC, anonymous wrote:
>> `zmod.symbol` works, too.
> no, it's not. at least on latest GDC.

Works for me with Ubuntu's gdc 4.8.2-1ubuntu6. My little test case:

my/module_.d:
---
module my.module_;
public import other.module_;
---

other/module_.d:
---
module other.module_;
int symbol;
---

mainprogram.d:
---
module mainprogram;
import zmod = my.module_;
static assert(is(typeof(zmod.symbol) == int)); /* passes */
---

>> I don't think so. The point of the renamed import is that you have to use the new name.
> but i renamed only my.module, not others. nothing hints me that renaming is SO global. it's counterintuitive.

Checking the documentation, it's a little unclear. You might be right in your expectations:

"An import can be specifically declared public, when it will be treated as if any imports of the module with the ImportDeclaration [here: my.module_] also import the public imported modules [other.module_]."[1]

That doesn't mention renamed imports, though. Are those generated imports supposed to be renamed, too? If so (apparently current behaviour), you'd have to write `zmod.symbol`. If not (what you expected), just `symbol` should work.

Personally, I think the current behaviour is fine. Renamed imports are supposed to guard you against name clashes. If public imports wouldn't get renamed, too, that guard would be circumvented.


[1] http://dlang.org/module.html#ImportDeclaration

On Tuesday, 29 April 2014 at 10:44:44 UTC, bearophile wrote:
> The current implementation of the module system has some problems, that are being worked on. If you think some part of the module system design is not good enough, then try to ask for an enhancement :-) No need to be sad.
ah, i can't clearly express myself even in this case, i don't think i can make clear request. it's easier to write code, not words. ;-)

i'm sad not about D or module issues, i'm sad about myself.

On Tuesday, 29 April 2014 at 10:57:13 UTC, Artur Skawina via Digitalmars-d-learn wrote:
> The D module system has a lot of problems and certainly needs
> to be completely redesigned from scratch
i don't see any real flaws in it. it's just little inconsistencies that can be easily fixed.

On Tuesday, 29 April 2014 at 11:10:06 UTC, anonymous wrote:
> Works for me with Ubuntu's gdc 4.8.2-1ubuntu6.
ah, don't you believe that i *really tested* it before posting, with latest GDC from git (which i builds routinely on dayly basis)?

> Personally, I think the current behaviour is fine. Renamed imports are supposed to guard you against name clashes. If public imports wouldn't get renamed, too, that guard would be circumvented.
to guard me from name clashes explicitly from the module i imported, not from the others. perhaps there should be some way to either rename all imports including public from module, or only the module itself, leaving it's public imports intact. if i'll invent nice syntax for it, i'll fill enhancement request with a patch.