Import proposals (Discuss)

[Derek Parnell]

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