Import concerns revisited

[Dave]

Sean Kelly wrote:
> Walter Bright wrote:
>> Dave wrote:
>>> Walter, I think what most are getting at here is that the 'as' syntax 
>>> just seems cleaner and more efficient from a coding and maintenance POV.
>>>
>>> If it's easy to implement, then I say go for it. If nothing else, 
>>> people can still use 'explicit' aliasing. I argue that 'as' will 
>>> actually be quicker for newbies to grasp (*especially* when they see 
>>> it in example code), and my sense is that it will be a boon to 
>>> maintenance because it generally won't end-up buried in the middle of 
>>> a module like many aliases would be. It's not like alias will be a 
>>> wasted feature - most prominently it will be used for storage types; 
>>> it just feels more 'natural' that way.
> 
> (I'm pretty tired so forgive me for being succinct/unclear)
> 
>> I think you're saying that this is not a discussion about 
>> functionality, but about aesthetics. I agree with that.
>>
>> A couple of people have brought up the alias-in-the-middle thing:
>>
>> 1) If it's in the middle because it's in a nested scope, then it only 
>> applies for the duration of that scope. Presumably, it would be easily 
>> visible to anyone looking at that scope.
>>
>> 2) I think we can all agree that if it is at module scope in the 
>> middle, that is probably bad coding style - especially if there are 
>> forward references to it.
> 
> Certainly.  However, it's been my experience that the vast majority of 
> programmers on any given project tend not to be particularly scrupulous 
> with their coding style, and code quality tends to degenerate over time. 
>  Therefore, I believe that any means available to encourage good coding 
> style and ease readability is worth considering quite carefully.  Having 
> literally tossed old projects in the trash because the cost of 
> maintenance was actually higher than a complete rewrite, I really can't 
> stress this point enough.  But please note that I'm not suggesting a 
> language or tool should in any way "dumb itself down" for the user, only 
> that aesthetics plays a significant role in determining whether a 
> particular feature or technique will be successful.
> 

Exactly - I couldn't have said it better.

>> 3) The with-import-as won't eliminate bad coding style with aliases. 
>> One can still plop an alias down in the middle of the module.
> 
> I do believe that bad code typically results from a few common causes:
> 
> * The programmer honestly doesn't know any better.  Often he's a novice 
> or simply hasn't been exposed to the level of programming required for 
> the task assigned.
> 
> * The programmer knows better but is in a hurry and doesn't care about 
> cutting a few corners.  He'll go back and fix it when there's more time. 
>  And that time will never be available.
> 

Great point.

> In both of these cases, language aesthetics makes a difference.  In the 
> first case, a mentor could suggest an alternate approach.  For this to 
> succeed the learning programmer must be able to remember the solution 
> and it must be fairly easy to execute.  If not, the programmer is 
> destined to become a member of the second category, as he now knows 
> better but finds some excuse not to use the technique anyway, often 
> because he can't remember the details or because it requires too much 
> typing.  In both cases, having support for the suggested technique built 
> into the language or tool is ideal, as it presents both a syntactical 
> reminder and a simpler way to accomplish the task than the programmer 
> would be inclined to use otherwise.  Finally, if the technique *looks 
> better* than another method and it's used pervasively, it will typically 
> be followed by others (the broken window problem).
> 

Exactly.

>> 4) At least with aliases, they need to be defined within the module. 
>> This means one can do a simple search of one source file to find any 
>> aliases.
> 
> Given the size of some of the source files I've seen, even a directed 
> keyword search may take some time.  This simply doesn't compare to a 
> glance at the import line.
> 
>> Let's look a bit at the aesthetics:
>>
>>     with foo.bar import
>>         abc as def,
>>         ghi as jkl,
>>         mno;
>>
>>     import very.long.name as N;
>> vs:
>>     static import foo.bar;
>>         alias foo.bar.abc def;
>>         alias foo.bar.ghi jkl;
>>         alias foo.bar.mno mno;
>>
>>     import very.long.name;
>>         alias very.long.name N;
>>
>>
>> Yes, the latter is more typing. If one was to do this a lot, it can 
>> get annoying. But is it going to be done a lot? I think that is the 
>> crux of the matter.
> 
> Assuming the language stays as-is, I believe the aliasing will likely be 
> limited to instances where collisions occur, as the technique is easy to 
> forget and requires a lot of typing.  I expect this will also lead to 
> maintenance issues as library upgrades cause symbol collisions and such.
> 

Again, exactly.

> As for qualifiers themselves, I expect the typical module name to be at 
> least two levels deep:
> 
>     import product.package.module;
> 
> and often more for large libraries.  Mango is a useful reference here, 
> and serves to support this assertion.
> 
>> P.S. There are other possible syntaxes:
>>
>>     import foo.bar
>>     {    def = abc,
>>         jkl = ghi,
>>         mno,
>>     }
> 
> As long as the syntax is aesthetically pleasing and 
> logically/structurally similar to Kris' proposal, I won't bicker over 
> minutiae.  That isn't too say I'm overly fond of the syntax you just 
> suggested, but I do understand that a slightly different syntax may 
> parse more easily or  better fit the 'feel' of the language as a whole.
> 

The exact implementation I leave to Walter (if the statement still 
starts with '[private] import' ;))

> 
> Sean