import RFC

[Jari-Matti Mäkelä]

Sean Kelly wrote:
> Jari-Matti Mäkelä wrote:

Thanks for the reply. First of all I didn't mean to start this thread
redundantly all over again. I just happened to miss that huge thread
after reading other 500+ posts. Uh, I was gone only about a week and
things have really gone forward - the general point of interest has
focused on more relevant things. I'm eagerly waiting for 1.0 now.

> 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.

Correct me if I'm wrong, but I thought all these things around import
are related. I've read now ~ 25% of the recent posts about imports and
it seems that when one talks about functionality, the other has selected
style of syntax as the starting point. I'm personally more interested in
language functionality and think we should find a consensus on
functional guidelines before going into syntax details (e.g. whether
'as' is a good keyword or not).

One of the core issues IMO is to know, whether modules 'inherit' the
namespace of the 'grandparent' module by default (or should it be made
optional) and how do we access these symbols and what are the FQS rules
on a general level.

> * 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 :-)

If you mean "conflicts with %s at %s", it's pretty normal with unsafe
imports when one does not use FQS names. Having a broken handling of
protection attributes doesn't help either, but that has been discussed
elsewhere.

> 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.

It should be enough the control the accessibility with protection
attributes. Importing individual module members is a bit overkill. I
don't have any previous experience on that matter (Java has only one
public top-level "module" member and no templates nor delegates), but I
suppose it could possible cause some missing dependencies.

> * 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.

Yes, I agree. As a said before, we're mixing apples and oranges here.
For me (and I think many pragmatic applications programmers, not
compiler experts) the most important syntactical aspect is to have a
consistent, elegant and easy to parse language. It should be as simple
as possible, but also extensible. Functionally wise there should be
consensus on what things should be allowed and what things are illegal
by design.

-- 
Jari-Matti