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