Import proposals (Discuss)

Rémy Mouëza ray.jay.ay.moueza at DoNtSpAm.gmail.com
Mon Jul 10 11:39:54 PDT 2006


In article <iq7sr366x54o$.11elk5mgt7qt0$.dlg at 40tude.net>, Derek Parnell says...
>
>On Mon, 10 Jul 2006 11:04:39 +1200, Regan Heath wrote:
>
>> Sub-thread for discussions
>
>What are the problems that this discussion is trying to solve?
>
>I submit these problems:
>
>Problem A: How does one write code to tell readers of source code (people
>and IDEs) which module a referred to member exists in?
>
>  Example:
>      import aaa;
>      import bbb;
>      ...
>      funcA(); // Is this in aaa, bbb, or the current module?
>
>Problem B: How does one disambiguate identically named accessible members
>that happen to be in the same scope and whose signatures match?
>
>      import aaa;
>      import bbb;
>      ...
>      funcB(); // Is this calling the funcB in aaa, or the one in bbb?
>
>Problem C: How does one force the use of Fully Qualified Name references?
>
>There exists in the current D, techniques to solve problems A and B, but
>not C. 
>
>One can use a simple Fully Qualified Name syntax or the alias syntax to
>resolve (A) and (B).
>
>      import aaa;
>      import bbb;
>      aaa.funcA();
>      bbb.funcB();
>
>or
>
>      import aaa;
>      import bbb;
>      alias aaa.funcA funcA;
>      alias bbb.funcB funcBb;
>      alias aaa.funcB funcBa;
>      ...
>      funcA;
>      funcBb();
>
>But why would these solutions need improving?
>
>I think it is because they are not efficient from a code writer and
>reader's point of view. If one is forced to always use FQN, it increases
>the burden on coders and readers because there are more characters to
>process and much of those are redundant. The alias technique is a partial
>solution as it significantly reduces clutter, but it is still not optimal
>because it causes a redundant typing and reading to be done, and has the
>potential to increase maintenance costs if the alias and import statements
>are separated in the source code.
>
>A better syntax would remove redundancy and localize the declarations for
>easier maintenance. Additional constraints would be to minimize the
>introduction of new keywords so as to avoid clashing with existing source
>code, and to permit backward compatibility for existing programs.
>
>      import in std.string 
>              split, 
>              find alias find_str;
>      import in bbb 
>              find alias find_re;
>      ...
>      split(. . .);
>      find_re(. . .);
>
>The "in" keyword would signal to the compiler that restricts imported names
>to only the list of members named after the module, and thus all other
>public members in the module are not allowed to be accessed. The "alias"
>keyword gives the imported member a new identity within the current module.
>
>In order to force the use of FQN, an additional qualifier, or form of the
>import statement, is required because this is independent of the restricted
>importing concept. 
>
> static import std.string; // All references must use FQN.
> static import in std.regexp find; // Only 'find' is imported and needs a
>FQN.
> static import in std.stdio writefln alias print; 
>
> . . .
> std.string.find( . . . );  // okay
> std.regexp.find( . . . );  // okay
> std.regexp.replace(. . .); // not okay (name not imported).
> std.stdio.print(. . .);  // okay
> print(. . .) // not okay as static import requested.
>
>
>The "static" keyword (yes I know ... another overloading ... sigh) tells
>the compiler that the names (and any aliases) in the imported module are
>fixed (static) and must be referenced via a FQN.
>
>A possible further optimization to support FQN would be to allow an alias
>for the *package.module* name as a whole to allow easier maintenance.
>
> static import std.string alias s;
> import std.regexp alias r;
>
> s.replace( . . . );
> r.replace( . . . );
>
>
>All these forms could be used in conjunction with each other and with
>existing code.
>
>IMPORT :: [static] import MODULENAMELIST;
>MODULENAMELIST :: IMPORTMODULE [, MODULENAMELIST]
>IMPORTMODULE :: [in] MODULENAME [alias ID] [MEMBERLIST]
>MEMBERLIST :: IMPORTMEMBER [, MEMBERLIST]
>IMPORTMEMBER:: ID [alias ID]
>
>
>-- 
>Derek
>(skype: derek.j.parnell)
>Melbourne, Australia
>"Down with mediocrity!"
>10/07/2006 12:33:51 PM

This idea is very close to what Python do. I like it. It seems readable,
understandable and looks like D code. 
>      import in std.string 
>              split, 
>              find alias find_str;
>      import in bbb 
>              find alias find_re;

In Python one would write :
from std.string import split, find as find_str
from bbb import find as find_re

Fully qualified name is the default in Python. If one want to import all the
symbols of a module :
from a.module import *
That is not considered as a best practice. 

Derek's proposal would make FQN as optional. If we prefer to make FQN mandatory,
we will have to find something to express the import of all the symbol of a
module, a kind of shortcut.
Justin (jcc7) idea of replacing alias with = is also interesting. 
There was also a proposal to use the 'with' keyword...

Ok. So here is my new mix of ideas : 
1) Fully Qualified Name is the default. 
2) Change the keywords a little bit :
import my.package.module ; // The symbols of this package have to be fully
qualified.
import with std.string  split, find = find_str ; // Nothing new,
import with std.regexp find = find_re ; // keyword have just changed.
Or we can keep the alias keyword :
import with std.string  split, find alias find_str ;
import with std.regexp find alias find_re ;
3) Allow the import of all the symbol of a module in the current namespace.
import with std.stdio in this ; 

In brief, nothing new except the FQN is mandatory. One have to import all the
symbols of a module in the current namespace to get the import behaviour we
currently have.








More information about the Digitalmars-d mailing list