Proposal for an extension to the import syntax

John Reimer terminal.node at gmail.com
Mon Dec 11 14:59:21 PST 2006


On Mon, 11 Dec 2006 12:39:36 -0800, Chris Nicholson-Sauls  
<ibisbasenji at gmail.com> wrote:

> Downs wrote:
>> At the moment the phobos standard library packages form a very flat  
>> structure.
>> However, it can be anticipated that with the availability of a 1.0  
>> spec, more libraries written natively in D will arise.
>> These libraries may have a far deeper and more branched package  
>> structure.
>> Since D does not have a construct similar to Java's "import module.*",
>> this will lead to pagefuls of import, consisting mostly of redundant
>> information, and we all know redundancy is sin ^^
>> Thus I propose an extension to the import syntax similar in meaning to  
>> the following example:
>>   import package.sub_package.vendor.[module_a, module_b, module_c];
>> These groups could possibly be used recursively, e.g.
>>   import package.sub_package.vendor.[module_a.[sub1, sub2], module_b];
>>  Any feedback, improvements, criticisms are appreciated.
>> Greetings.
>
> I'll say this much.  Generally speaking, I am against adding anymore to  
> D's import system as it stands -- it was an amazing sight when we got  
> private-by-default, import aliasing, selective imports, and static  
> imports.  All of these things which had been wanted at one time or  
> another, and thought impossible to achieve all at once.  But Walter had  
> one of his genius moments and invented a syntax that does provide all  
> these, in a very reasonable manner.  (Go W!)  However, in the process,  
> he did make it a little fragile.  I don't know if it could handle having  
> anymore shoved into it than it has now.
>
> /BUT/, I do have to admit your syntax at the very least is strangely  
> compelling.  ;)  I think the longest import list I've ever had in a  
> single module (not counting umbrella modules) was about ten.  I consider  
> ten to be perfectly acceptable; so I don't know if I agree about deep  
> libraries (Mango can get there sometimes) causing a problem... but I  
> guess massive multi-libs and such might later on.
>
> It has my cautious vote.
>
> -- Chris Nicholson-Sauls


Massive imports will happen.  It's only a matter of time as huge projects  
start rolling out.  "all.d" has been a popular workaround.  But, once  
again, I think all.d is not optimal and only acts as a red flag that  
reveals a future need.

I think in circumstances like this, Walter is willing to wait until  
experience forces the issue back to the forefront (and I think it will  
reappear). In fact, I'm sure this is the way many new D features will  
appear in the future, especially as complex cases start identifying needs  
in large commercial projects.

I do think we need a muli-import style eventually -- something that is  
safe, something that is clear in regards to intent.  The suggestion made  
by downs is a start and shows a alertness to the potential problems of a  
multi-import syntax.  Maybe the idea can be further developed to improve  
the syntax.

-JJR



More information about the Digitalmars-d mailing list