import RFC

Jari-Matti Mäkelä jmjmak at utu.fi.invalid
Tue Jul 11 08:11:01 PDT 2006


kris wrote:
> Unfortunately, the conversion to pdf lost some of the formatting.  Take
> it for what it is:
> 
> http://larsivi.net/files/ImportIssues.pdf

Has someone set up a poll already somewhere? I suppose a majority of D
users are with you. FQS is definitely not the way to go - hey, even
Eclipse automatically converts those FQS:s to imports in order to avoid
confusion. Still this 'safe import' -approach has some drawbacks.

At first I thought about something like implicit "static" private import
of modules within the same package, but could it possibly cause naming
conflicts? AFAIK the modules have a 1-to-1 correspondence with physical
file names and it's impossible to have 2+ files with exactly the same
file path and file name on many file systems.

I have a framework of ~100 stub/skeleton classes (no implementation,
just method & class names). These classes are almost all in different
modules because the implementation details need to be private for real.
One problem is that doing import in the 'safe' way results in lot of
redundant code:

import path.to.foo as foo;
import path.to.bar as bar;

auto a = new foo.Foo(1, 2)
auto b = new bar.Bar(3, 4);
bar.Bar.doStaticMethod();
//...and so on

It should be somehow possible to import these symbols to the "top level"
of the local namespace - but prevent the compiler from chaining these
imports further(module xyz gets access to symbols in foo by importing
bar when bar imports foo). I really haven't quite even started the
project yet and by judging all the proposed import systems the situation
looks a bit bleak. I would rather code all this stuff in Java.

Perhaps my solution would be to allow both unsafe and safe imports, but
prevent the compiler from chaining the imports. The default behaviour
would be to import to the "top level" of the namespace, to avoid
conflicts the alternative syntax would be to support this proposed
syntax (import a.b.c.foo as foo):

module foo:

 class A {}

module bar:

 class A {}
 class B {}

module xyz:

 import foo;
 public import bar as bar; // allows chaining

 class C {}

 auto a = new A(); // A from foo
 auto b = new bar.A(); // A from bar
 auto c = new bar.B(); // B from bar
 //auto d = new B(); // not allowed

module abc:

 import xyz;

 auto a = new C(); // C from xyz
 auto b = new A(); // not allowed
 auto c = new bar.B(); // B from bar


What do you think?

-- 
Jari-Matti



More information about the Digitalmars-d mailing list