View mode: basic / threaded / horizontal-split · Log in · Help
August 17, 2005
Re: import statements inside unittests
In article <de04ab$b14$1@digitaldaemon.com>, Ben Hinkle says...
> Should the imported 
>symbols only be visible after the executed statement or throughout the scope 
>body? . Also given that imports inside classes and structs are discouraged 
>(and undocumented I believe) by Walter

Why do you say that?

"The top level scope in the module is merged with the current scope."
from http://www.digitalmars.com//d/index.html

I see no limitation on "current scope", but I remember a compiler message
about the scope of the import declaration.

Ant
August 17, 2005
Re: import statements inside unittests
Hi,

>> Hi,
>> What about arbitrarily nested import statements?
>> Seems more useful than a special case for unittest.
>> --AJG.
>
>Yeah - I'm worried about what it actually means, though. Should the imported 
>symbols only be visible after the executed statement or throughout the scope 
>body? . 

I'm not saying I know "the" answer to this one, nor is this a feature I'm
desperate about, but to me it would mean something like the following:

~Foo.d:
# mFooSymbol; // ERROR.
# mBarSymbol; // ERROR.
# mBazSymbol; // ERROR.
#
# import mFoo;
# mFooSymbol; // OK.
# mBarSymbol; // ERROR.
# mBazSymbol; // ERROR.
#
# class Bar {
#     mFooSymbol; // OK.
#     mBarSymbol; // ERROR.
#     mBazSymbol; // ERROR.
#
#     import mBar;
#     mFooSymbol; // OK.
#     mBarSymbol; // OK.
#     mBazSymbol; // ERROR.
#
#     void Baz() {
#          mFooSymbol; // OK.
#          mBarSymbol; // OK.
#          mBazSymbol; // ERROR.
#
#         import mBaz;
#         mFooSymbol; // OK.
#         mBarSymbol; // OK.
#         mBazSymbol; // OK.         
#     }
#
#     mFooSymbol; // OK.
#     mBarSymbol; // OK.
#     mBazSymbol; // ERROR.
# }
#
# mFooSymbol; // OK.
# mBarSymbol; // ERROR.
# mBazSymbol; // ERROR.

Don't know if I missed any cases in there.

>Also given that imports inside classes and structs are discouraged 
>(and undocumented I believe) by Walter I'd imagine that putting them inside 
>functions will be even more hairy.

Do you mean semantically or in terms of the compiler's own implementation?

Cheers,
--AJG.
August 17, 2005
Re: import statements inside unittests
"Ant" <Ant_member@pathlink.com> wrote in message 
news:de050d$blb$1@digitaldaemon.com...
> In article <de04ab$b14$1@digitaldaemon.com>, Ben Hinkle says...
>> Should the imported
>>symbols only be visible after the executed statement or throughout the 
>>scope
>>body? . Also given that imports inside classes and structs are discouraged
>>(and undocumented I believe) by Walter
>
> Why do you say that?
>
> "The top level scope in the module is merged with the current scope."
> from http://www.digitalmars.com//d/index.html
>
> I see no limitation on "current scope", but I remember a compiler message
> about the scope of the import declaration.
>
> Ant

That sentance appears in the 'module' page. No mention of importing other 
than at the top level of a module is made in the D docs (from what I could 
tell). The production DeclDefs in module.html is the only place I could find 
imports explicitly listed in the "grammar" such as it is. For example the 
next section "Scope and Modules" only talks about importing a module into 
another module. The classes.html doc doesn't talk about importing or what it 
means (in general the classes.html never seems to actually say what's 
allowed inside a class body). If one interprets "current scope" as really 
meaning any scope then it would also include function scopes - which 
currently doesn't work. So I think attaching too much meaning to the words 
"current scope" is dangerous - the web pages are .. umm... informal.

I also briefly tried searching for a post I recall where he suggested people 
avoid importing inside class bodies even though it technically works 
(depending on bugs, I think). None of the threads with the obvious subject 
names had anything useful and it's impossible to search those long 
meandering threads with generic subjects. I know several people argued 
strongly that they try to import inside classes as much as possible so it's 
a touchy subject.
August 17, 2005
Re: import statements inside unittests
On Wed, 17 Aug 2005 16:47:54 -0400, Ben Hinkle wrote:


[snip]

> No mention of importing other than at the top level of a module is made in
> the D docs (from what I could tell). The production DeclDefs in module.html
> is the only place I could find imports explicitly listed in the "grammar"
> such as it is ...

Backing up a little ... it would be useful if Walter could provide an
easy-to-use mechanism so that specific imports only occurred during unit
testing.

-- 
Derek Parnell
Melbourne, Australia
18/08/2005 6:56:15 AM
August 17, 2005
Re: import statements inside unittests
"AJG" <AJG_member@pathlink.com> wrote in message 
news:de069s$cpb$1@digitaldaemon.com...
> Hi,
>
>>> Hi,
>>> What about arbitrarily nested import statements?
>>> Seems more useful than a special case for unittest.
>>> --AJG.
>>
>>Yeah - I'm worried about what it actually means, though. Should the 
>>imported
>>symbols only be visible after the executed statement or throughout the 
>>scope
>>body? .
>
> I'm not saying I know "the" answer to this one, nor is this a feature I'm
> desperate about, but to me it would mean something like the following:
>
> ~Foo.d:
> # mFooSymbol; // ERROR.
> # mBarSymbol; // ERROR.
> # mBazSymbol; // ERROR.
> #
> # import mFoo;
> # mFooSymbol; // OK.
> # mBarSymbol; // ERROR.
> # mBazSymbol; // ERROR.

This part so far is different than D today. mFooSymbol is available in the 
first line.

> # class Bar {
> #     mFooSymbol; // OK.
> #     mBarSymbol; // ERROR.
> #     mBazSymbol; // ERROR.
> #
> #     import mBar;
> #     mFooSymbol; // OK.
> #     mBarSymbol; // OK.
> #     mBazSymbol; // ERROR.

This is different, too.

> #     void Baz() {
> #          mFooSymbol; // OK.
> #          mBarSymbol; // OK.
> #          mBazSymbol; // ERROR.
> #
> #         import mBaz;
> #         mFooSymbol; // OK.
> #         mBarSymbol; // OK.
> #         mBazSymbol; // OK.
> #     }
> #
> #     mFooSymbol; // OK.
> #     mBarSymbol; // OK.
> #     mBazSymbol; // ERROR.
> # }
> #
> # mFooSymbol; // OK.
> # mBarSymbol; // ERROR.
> # mBazSymbol; // ERROR.
>
> Don't know if I missed any cases in there.
>
>>Also given that imports inside classes and structs are discouraged
>>(and undocumented I believe) by Walter I'd imagine that putting them 
>>inside
>>functions will be even more hairy.
>
> Do you mean semantically or in terms of the compiler's own implementation?
>
> Cheers,
> --AJG.
>

Personally if putting restrictions on the places where imports are allowed 
helps make compilers simpler and less buggy (eg Java forces all imports at 
the top) then I'm all for it. The current documentation on imports is very 
vague.
August 17, 2005
Re: import statements inside unittests
"Derek Parnell" <derek@psych.ward> wrote in message 
news:1jg0ds14poumr.gmvd6saz5sez$.dlg@40tude.net...
> On Wed, 17 Aug 2005 16:47:54 -0400, Ben Hinkle wrote:
>
>
> [snip]
>
>> No mention of importing other than at the top level of a module is made 
>> in
>> the D docs (from what I could tell). The production DeclDefs in 
>> module.html
>> is the only place I could find imports explicitly listed in the "grammar"
>> such as it is ...
>
> Backing up a little ... it would be useful if Walter could provide an
> easy-to-use mechanism so that specific imports only occurred during unit
> testing.
>
> -- 
> Derek Parnell
> Melbourne, Australia
> 18/08/2005 6:56:15 AM

ok - that's the point of this thread. Was there some confusion I missed? AJG 
was generalizing the original proposal.
August 17, 2005
Re: import statements inside unittests
"Victor Nakoryakov" <nail-mail@mail.ru> wrote in message 
news:ddv03k$2aug$1@digitaldaemon.com...
> Hi all.
>
> Is there any reason for forbiding import statements inside unittests?
> I often want import some module just for testing purposes only and do not 
> want keep this dependency in release builds.
>
> -- 
> Victor (aka nail) Nakoryakov
> nail-mail<at>mail<dot>ru
>
> Krasnoznamensk, Moscow, Russia

Actually now that I think about it why is "private import" inadequate? A 
private import should have no effect on modules that import the original 
module.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home