www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Import modules too verbose in some cases

reply Johnson Jones <JJ Dynomite.com> writes:
Sometimes one doesn't want to import either the whole module nor 
specify a single function to import. It seems that basically D 
has all the info to import the function implicitly because it 
usually gives a nice error message tells us which module to 
import for the function.

e.g.,

A.B.C()

"Did you forget to import module A.B?"

and so we have to do

import A.B;
A.B.C();

Sometimes we still need to specify the fully qualified name due 
to conflicts with other modules.


Rather, how about a new feature were we do not have to import 
modules at all by specifying the fully qualified name? Since 
conflicts might occur, how bout using a symbol to express that?

#A.B.C();

or

 A.B.C();

or

$A.B.C();

same as

import A.B;
A.B.C();


So, for one offs we don't have to write the import statement.
Aug 09
next sibling parent Rene Zwanenburg <renezwanenburg gmail.com> writes:
On Wednesday, 9 August 2017 at 23:57:19 UTC, Johnson Jones wrote:
 Sometimes one doesn't want to import either the whole module 
 nor specify a single function to import. It seems that 
 basically D has all the info to import the function implicitly 
 because it usually gives a nice error message tells us which 
 module to import for the function.
It doesn't have that information available, and that's unlikely to change due to the compilation model. Rather, a few very common cases have been hardcoded in the compiler: https://github.com/dlang/dmd/blob/4d86fcba2fd2ef86cc85738cd2ac2b059dbb5800/src/ddmd/imphint.d
Aug 10
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 9 August 2017 at 23:57:19 UTC, Johnson Jones wrote:
 Sometimes one doesn't want to import either the whole module 
 nor specify a single function to import.
There was a proposal called "dependency carrying declarations" about that, but a library trick was found to beat it: https://github.com/dlang/druntime/pull/1756 They called it "self-important lookups"...though the PR was never actually merged, but as you can see in there, the code was actually quite trivial (the PR is about 95% documentation): template from(string moduleName) { mixin("import from = " ~ moduleName ~ ";"); } So then you can do an inline import and reference right there.
 It seems that basically D has all the info to import the 
 function implicitly because it usually gives a nice error 
 message tells us which module to import for the function.
It is guessing there, giving a hint to users but it doesn't actually have enough information to fix it automatically. Consider: struct A { static struct B { static void C() {} } } in that case A.B.C() is the struct function, not an import. The line between the package+module and the inner symbol is unknown without an import.
 Sometimes we still need to specify the fully qualified name due 
 to conflicts with other modules.
Keep in mind too that you can do renamed imports: import short = some.long.name; short.foo(); // refers to some.long.name.foo();
 Rather, how about a new feature were we do not have to import 
 modules at all by specifying the fully qualified name? Since 
 conflicts might occur, how bout using a symbol to express that?

 #A.B.C();
This is what the `from!"A.B".C()` trick linked above enables. But notice that the module is in quotes - it still doesn't know where where the line is drawn between module and inner name without you telling it somehow.
Aug 10