Import concerns revisited

[Sean Kelly]

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.

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

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

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

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.


Sean