www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - import with renaming and public import inside module

reply "ketmar" <ketmar ketmar.no-ip.org> writes:
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?
Apr 27 2014
parent reply "anonymous" <anonymous example.com> writes:
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.



 Apr 28 2014



  parent reply "ketmar" <ketmar ketmar.no-ip.org>  writes:


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.



 Apr 29 2014



 next sibling parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


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



 Apr 29 2014



  parent reply "ketmar" <ketmar ketmar.no-ip.org>  writes:


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.



 Apr 29 2014



  parent reply "bearophile" <bearophileHUGS lycos.com>  writes:


ketmar:


 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.


One of the most important skills of a programmer (and of course a 
technical/literary writer) is the ability to express ideas in 
written text. It's a skill that you develop doing exercise, 
pushing yourself, finding the sub-parts you are weaker and 
exercising on them in a focused way, and reading good non-fiction 
and fiction.

Bye,
bearophile



 Apr 29 2014



  parent reply "ketmar" <ketmar ketmar.no-ip.org>  writes:


On Tuesday, 29 April 2014 at 11:28:23 UTC, bearophile wrote:

 One of the most important skills of a programmer (and of course 
 a technical/literary writer) is the ability to express ideas in 
 written text.


the thing is that English neither my native language nor i 
learned it in school (not really learned it at all in fact). i 
can express myself in russian, ukrainian and some obscure 
artificial language, but this will be of little use for the rest 
of the community. ;-) i can easily read English, but my writing 
skills are close to nothing.



 Apr 29 2014



  parent  "bearophile" <bearophileHUGS lycos.com>  writes:


ketmar:


 the thing is that English neither my native language


Nor mine, as you can see :-) And I am bad with natural languages 
in general. But you can learn to write "acceptable" English if 
you do exercises for some years :-)

Bye,
bearophile



 Apr 29 2014



prev sibling next sibling parent reply Artur Skawina via Digitalmars-d-learn <digitalmars-d-learn puremagic.com>  writes:


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



 Apr 29 2014



 next sibling parent  "bearophile" <bearophileHUGS lycos.com>  writes:


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



 Apr 29 2014



prev sibling  parent  "ketmar" <ketmar ketmar.no-ip.org>  writes:


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.



 Apr 29 2014



prev sibling  parent reply "anonymous" <anonymous example.com>  writes:


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



 Apr 29 2014



 next sibling parent reply "ketmar" <ketmar ketmar.no-ip.org>  writes:


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.



 Apr 29 2014



  parent reply "anonymous" <anonymous example.com>  writes:


On Tuesday, 29 April 2014 at 11:23:56 UTC, ketmar wrote:

 ah, don't you believe that i *really tested* it before posting, 
 with latest GDC from git (which i builds routinely on dayly 
 basis)?


You may have made mistakes when testing, or maybe I have. That's 
why I provided my testcase. Does it work in your setup? If not, 
you may want to file a bug with GDC, as it's supposed to work, as 
far as I can see.


 to guard me from name clashes explicitly from the module i 
 imported, not from the others.


The other, current behaviour is more defensive. And it's what I'd 
expect, so I'm fine with it.


 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.


I don't have a need for that feature. And I don't think there is 
ample demand. I don't see how `zmod.symbol` or two imports are 
bad enough to warrant it. But I don't have any kind of authority 
here, so go for it, if you think it's worthwhile.



 Apr 29 2014



  parent  "ketmar" <ketmar ketmar.no-ip.org>  writes:


On Tuesday, 29 April 2014 at 11:47:07 UTC, anonymous wrote:

 You may have made mistakes when testing, or maybe I have.


sorry again for being rude. i was really upset and 
unintentionally made it to you.


 That's why I provided my testcase. Does it work in your setup?


your sample is ok. but derelict sdl is bad (there are more public 
imports in it).


 The other, current behaviour is more defensive. And it's what 
 I'd expect, so I'm fine with it.


that's why i want an option to do it my way. ;-)


 I don't have a need for that feature.


and i see. this additional feature will not break anything if 
done properly, but will add a thing for those who need it.



 Apr 29 2014



prev sibling  parent reply "ketmar" <ketmar ketmar.no-ip.org>  writes:


On Tuesday, 29 April 2014 at 11:10:06 UTC, anonymous wrote:
specifically, it was derelict sdl bindings. that module itself 
does public imports, so issue is more complicated. sorry for me 
being rude.



 Apr 29 2014



  parent reply Mike Parker <aldacron gmail.com>  writes:


On 4/29/2014 8:25 PM, ketmar wrote:

 On Tuesday, 29 April 2014 at 11:10:06 UTC, anonymous wrote:
 specifically, it was derelict sdl bindings. that module itself does
 public imports, so issue is more complicated. sorry for me being rude.


What, exactly, is the problem you are having with public imports in 
Derelict?



 Apr 29 2014



 next sibling parent  "ketmar" <ketmar ketmar.no-ip.org>  writes:


On Tuesday, 29 April 2014 at 13:53:58 UTC, Mike Parker wrote:

 What, exactly, is the problem you are having with public 
 imports in Derelict?


it's not derelict issue, sorry is i made you to think that. issue 
is with the renamed public imports, and dereclit was one that 
triggered it. nothing bad with derelict, it's really cool by 
itself. ;-)



 Apr 29 2014



prev sibling  parent reply "ketmar" <ketmar ketmar.no-ip.org>  writes:


On Tuesday, 29 April 2014 at 13:53:58 UTC, Mike Parker wrote:
ah. besides that i was once unable to build derelict sdl due to 
undefined symbols like 'ipad' or so, can't really remember. but 
it's the thing you got when goind bleeding edge, i think.



 Apr 29 2014



  parent reply "ketmar" <ketmar ketmar.no-ip.org>  writes:


fuck. nobody approves my posts in mailing list. if i want to spam 
this forum — i can do it here. shit.



 Apr 29 2014



  parent  "ketmar" <ketmar ketmar.no-ip.org>  writes:


On Tuesday, 29 April 2014 at 21:21:10 UTC, ketmar wrote:
bye. will never write here again.



 Apr 29 2014