the point of selective importing
Rioshin an'Harthen
rharth75 at hotmail.com
Tue Jul 11 11:30:26 PDT 2006
"Rioshin an'Harthen" <rharth75 at hotmail.com> wrote:
> "Derek Parnell" <derek at psych.ward> wrote:
>> On Tue, 11 Jul 2006 21:12:59 +1000, Rioshin an'Harthen wrote:
>>> import module.name; - current import
>>> static import module.name; - require FQN import
>>> import module.name alias MN; - current import with automatic alias
>>> static import module.name alias MN; - require FQN import with automatic
>>> alias
>>
>> Snap! This was also my suggestion ;-) Additionally, I extended this idea
>> to also allow for selective imports of individual members from the module
>> rather than all the members.
>>
>> static import in module.name alias MN member1 alias m1, member2,
>> member3, ... ;
>>
>> MN.memb3()
>> MN.m1()
>
> Great minds, eh? :)
>
> I'm giving this a definite thumbs up. Sometimes, it's quite good to only
> import selected members (which I didn't take into account in my post - I
> would probably have come up with something akin to what you show).
A little further thought into this:
[<protection>] [static] import {[in]} <FQN Module> [alias <Module Alias>]
{[<<Member> [alias <Member Alias>]>[, ...]]};
where [] denotes optionality, {} requiring all if one, and <> a symbol name.
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. :) But it would fill
in the forms from my previous post:
import module.name;
foo(); // legal
module.name.foo(); // legal
mn.foo(); // illegal, no alias or as
import module.name alias mn;
foo(); // legal
module.name.foo(); // legal
mn.foo(); // legal
import module.name as mn;
foo(); // legal since not static import
module.name.foo(); // illegal since "as" is used
mn.foo(); // legal
static import module.name;
foo(); // illegal, static import
module.name.foo(); // legal
mn.foo(); // illegal, no alias or as
static import module.name alias mn;
foo(); // illegal, static import
module.name.foo(); // legal
mn.foo(); // legal
static import module.name as mn;
foo(); // illegal, static import
module.name.foo(); // illegal since "as" is used
mn.foo(); // legal
Not that I'm proposing this distinction - I believe it is an unnecessary
complication. I think "alias" is enough - we can use the fully qualified
name if necessary (sometimes, it's good for code clarity to use in a
function or method the fully qualified name, and then using the short form
created with an alias), while using the aliased form most of the time.
The import syntax could be something akin to (with the optional as in
brackets):
ImportDeclaration:
ProtectionAttribute 'static' ImportStatement ;
ProtectionAttribute ImportStatement ;
'static' ImportStatement ;
ImportStatement ;
ProtectionAttribute:
'private'
'public'
(and whatever others deemed necessary)
ImportStatement:
'import' 'in' ModuleDeclaration MemberDeclarationList
'import' ModuleDeclarationList
ModuleDeclarationList:
ModuleDeclaration
ModuleDeclaration , ModuleDeclarationList
ModuleDeclaration:
ModuleName 'alias' AliasedModuleName
[ModuleName 'as' AsModuleName]
ModuleName
MemberDeclarationList:
MemberDeclaration
MemberDeclaration , MemberDeclarationList
MemberDeclaration:
MemberName 'alias' AliasedMemberName
[MemberName 'as' AsMemberName]
MemberName
This grammar would allow for multiple modules to be imported on one line,
provided we don't try to import specific members from it, while allowing for
specific members to be imported (requiring one import statement per module
when only picking certain members from it).
More information about the Digitalmars-d
mailing list