Import concerns revisited

[Jari-Matti Mäkelä]

Walter Bright wrote:
> Jari-Matti Mäkelä wrote:
>> Walter Bright wrote:
>>> Not exactly what you're after, but consider the Java hello world
>>> program:
>>>
>>>   class HelloWorldApp {
>>>     public static void main(String[] args) {
>>>         System.out.println("Hello World!");
>>>     }
>>>   }
>>>
>>> There's a reason for everything there, but it's a little off-putting.
>>> Consider the D version:
>>>
>>>   import std.stdio;
>>>
>>>   void main() {
>>>      writefln("Hello World!");
>>>   }
>>
>> Changing the language syntax so that imports are private by default does
>> not change anything in either of those examples.
> 
> True. But what I think goes too far is requiring hello world to look like:
> 
>   import std.stdio;
> 
>   public void main() {
>      std.stdio.writefln("Hello World!");
>   }
> 
> It's not like it's wrong to design D that way, it's just off-putting.
> Simple things should be simple.

Agreed.

Although I don't think anyone particularly was suggesting that it should
be a default. According to
<http://www.prowiki.org/wiki4d/wiki.cgi?ImportConflictResolution> a
majority of active members only want to extend the import syntax so that
old programs would work exactly as they do now and new programs would
have better control over their namespaces. The 'static import' + some
aliasing would be more than enough to fix this but many coders are so
lazy (including me) they want import to support aliasing directly. ;)

Making the imports private wouldn't break any existing tutorial code
either since it requires at least two user modules for private imports
to have any effect. Most code snippets I've seen feature only one.

-- 
Jari-Matti