import RFC

[Sean Kelly]

Jari-Matti Mäkelä wrote:
> Sean Kelly wrote:
 >
>> Jari-Matti Mäkelä wrote:
> 
>> 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).

I think part of this simply stems from the fact that most user-driven 
changes to D originate from proposals rather than progressive design 
discussion.  So it's not uncommon for suggested syntax and such to be a 
part of the proposal, particularly in a case like this where aesthetics 
are an important aspect of the feature.  But I agree that this approach 
seems to result in unfocused discussion.

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

Definately.

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

So long as there is a way to expose only specific symbols imported from 
a parent module and to avoid collisions if the user imports both the 
parent and importing modules then I'll be happy.  From my 
experimentation there's currently no way to do this now.

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

Agreed.


Sean