import RFC

Sean Kelly sean at f4.ca
Tue Jul 11 10:30:32 PDT 2006


Jari-Matti Mäkelä wrote:
>
> 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 think the correct approach here would be to make all imports private 
and hope that the lookup mechanism changes so private symbols are truly 
invisible across module boundaries.  This came up briefly in the Mother 
Of All Threads above, but wasn't pursued since the import issue seemed 
perhaps more important.  But perhaps once the import syntax issue has 
been resolved, the topic could be revisited.  At the very least, I'm 
hoping that Walter will be able to find out why the C++ lookup rules 
(which D's are based on) were done the way they are, and whether any of 
the factors have any bearing on D.

As for the topic at hand, I feel that:

* "static import" is better than what we have now, but I'm not terribly 
keen on the need for an additional alias line to avoid FQS names (which 
I expect to commonly be quite long).  I know it's just an additional 
line of code, but this is a case where the need for an alias line may 
relegate the entire feature to the realm of the Exceedingly Careful.

* Some variation on the "as" syntax appears to be the best means of 
achieving readability, easing maintenance, and encouraging the use of 
what I feel is a good programming practice.  I also believe little 
things like this are crucial in deciding whether a particular feature or 
technique achieves common use.

* Selective import at the symbol level would be a terrific perk, but if 
worse came to worse I could live with some form of qualified import plus 
alias *assuming this technique would not cause "multiply defined symbol" 
errors*.  I'm quite certain I've had this problem in the past with the 
import/alias combination, and if this was simply a bug or if I was doing 
something wrong then I'd like to know :-)  Exposing only specific 
symbols of an imported module isn't terribly needful for user-level 
applications, but it is extremely useful for library design where any 
public symbol exposed by a module is considered a part of that module's 
interface.

* If some change is to occur, I would really prefer it be as 
aesthetically pleasing as possible.  Arcane syntax would risk relegating 
this feature to the dustbin for many programmers, and this is something 
I believe should be common practice for any serious project.

* Any well-designed implementation is likely to see a lot of use.  The 
concept has nearly universal support in discussion (only the details 
seemed to be at issue), and I know that Kris, myself, and many others 
would encourage the use of such a technique through example in our own 
library code and in any associated coding guidelines.  I'm not sure that 
this in itself is a panacea as your comments demonstrate, Jari, but I 
believe it is a good step towards supporting the development of large 
projects in D.


Sean



More information about the Digitalmars-d mailing list