the point of selective importing

[Jari-Matti Mäkelä]

Rioshin an'Harthen wrote:
> This would allow for example the following syntaxes:
> 
> private import module.name;
> import module.name alias mn;
> import in module.name member1, member2;
> import in module.name alias mn member1, member2 alias m2;
> private static import in module.name alias mn member1 alias m1, member2 
> alias m2, member3 alias m3;
> 
> (where I would probably write the last one as something like
> 
>     private static import
>         in module.name alias mn
>             member1 alias m1,
>             member2 alias m2,
>             member3 alias m3;
> 
> , but I digress).
> 
> It could even be considered that any occurence of alias be replaced with 
> alias|as, where | denotes that either but not both be used, and the 
> difference being alias allowing the use of both forms (FQN or aliased name), 
> while as requiring the use of the aliased name. However, this would be a 
> complexity I would not want to write into the compiler. :)

I guess that pretty much says that it's not appropriate to incorporate
such a complex syntax in D either. Remember, D is supposed to be
"simple" language. :)

I don't get it - why does one have to be able to access a symbol using
three different naming conventions *at the same time*. Why does not
'alias' and/or 'as' imply 'static'?  What's the benefit of using 'as'
instead of 'alias'? Why does one need to import individual module
members or alias those module members in the import statement?

I think 90% of that functionality can be achieved using only two
attributes/keywords: 'private' and 'alias'. Personally I would prefer
'public' over 'private' but I guess the default behaviour of imports is
not going to change anymore. I might understand why you would like to
have this complex syntax: to shorten/remove the annoying prefixes
preceding foreign module members, but it only makes the code less robust.

Consider a situation where one of the imported modules on the same
namespace gets an additional public member that conflicts with another
imported member. That leads to difficult exceptions logic in the import
statements. I would rather make the count of public module members as
small as possible and import the whole module to the top level namespace
(non-static, not as/alias) or give it an own namespace (static, alias,
not as). If needs be, there could also be an ability to import separate
members by concatenating the member name the member name with a leading
dot to the module name in the import statement. Much easier. In my
experience if your having more than 1-2 conflicting members, you're
doing something wrong.

-- 
Jari-Matti