Thread overview | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
August 17, 2013 scoped imports | ||||
---|---|---|---|---|
| ||||
Attachments:
| Is there a way to achieve this: ---- module foo; { import bar; void fun1(){bar.barfun();} void fun2(bar.BarType a){} } // now bar is not in scope anymore. void fun3(){} ---- This would reduce name clashes conflicts, ease refactorings and in general make code a bit cleaner. Related question: Why isn't the following allowed: ---- void fun(){ // code without version=A version=A; // code with version=A vesion(none): //code versioned out } ---- I understand the grammar doesn't allow it, but what's the rationale, and can it be fixed? |
August 17, 2013 Re: scoped imports | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | Timothee Cour:
> Is there a way to achieve this:
>
> ----
> module foo;
>
> {
> import bar;
> void fun1(){bar.barfun();}
> void fun2(bar.BarType a){}
> }
>
> // now bar is not in scope anymore.
Using a struct as namespace:
struct Foo {
import std.stdio;
static void bar(int x) { x.writeln; }
}
alias bar = Foo.bar;
void main() {
bar(10);
// writeln(20); // std.stdio out of scope
}
Bye,
bearophile
|
August 17, 2013 Re: scoped imports | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile Attachments:
| thanks. That's a bit clunky though, so it's unlikely to be used. Not sure what it would take to make the grammar allow it. On Sat, Aug 17, 2013 at 4:23 PM, bearophile <bearophileHUGS@lycos.com>wrote: > Timothee Cour: > > > Is there a way to achieve this: >> >> ---- >> module foo; >> >> { >> import bar; >> void fun1(){bar.barfun();} >> void fun2(bar.BarType a){} >> } >> >> // now bar is not in scope anymore. >> > > Using a struct as namespace: > > > struct Foo { > import std.stdio; > static void bar(int x) { x.writeln; } > } > alias bar = Foo.bar; > > void main() { > bar(10); > // writeln(20); // std.stdio out of scope > } > > > Bye, > bearophile > |
August 18, 2013 Re: scoped imports | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | On Saturday, 17 August 2013 at 22:30:14 UTC, Timothee Cour wrote:
> Is there a way to achieve this:
>
> ----
> module foo;
>
> {
> import bar;
> void fun1(){bar.barfun();}
> void fun2(bar.BarType a){}
> }
>
> // now bar is not in scope anymore.
> void fun3(){}
> ----
>
> This would reduce name clashes conflicts, ease refactorings and in general
> make code a bit cleaner.
Why not import bar _inside_ fun1 and fun2 ... ?
void fun1()
{
import bar;
barFun();
}
... should work, no?
|
August 18, 2013 Re: scoped imports | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joseph Rushton Wakeling Attachments:
| that's not DRY: in my use case, a group of functions use certain imports, it would be annoying and not DRY to do that. What I suggest (allowing {} grouping at module scope) seems simple and intuitive; any reason it can't be done?
On Sat, Aug 17, 2013 at 6:16 PM, Joseph Rushton Wakeling < joseph.wakeling@webdrake.net> wrote:
> On Saturday, 17 August 2013 at 22:30:14 UTC, Timothee Cour wrote:
>
>> Is there a way to achieve this:
>>
>> ----
>> module foo;
>>
>> {
>> import bar;
>> void fun1(){bar.barfun();}
>> void fun2(bar.BarType a){}
>> }
>>
>> // now bar is not in scope anymore.
>> void fun3(){}
>> ----
>>
>> This would reduce name clashes conflicts, ease refactorings and in general make code a bit cleaner.
>>
>
> Why not import bar _inside_ fun1 and fun2 ... ?
>
> void fun1()
> {
> import bar;
> barFun();
> }
>
> ... should work, no?
>
|
August 18, 2013 Re: scoped imports | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | On Sunday, 18 August 2013 at 01:33:51 UTC, Timothee Cour wrote:
> that's not DRY: in my use case, a group of functions use certain imports,
> it would be annoying and not DRY to do that. What I suggest (allowing {}
> grouping at module scope) seems simple and intuitive; any reason it can't be done?
How do you ensure that the imports are limited to your {} scope, but your functions are not, without a finnicky special case for how scopes work?
|
August 18, 2013 Re: scoped imports | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joseph Rushton Wakeling Attachments:
| On Sun, Aug 18, 2013 at 2:31 AM, Joseph Rushton Wakeling < joseph.wakeling@webdrake.net> wrote:
> On Sunday, 18 August 2013 at 01:33:51 UTC, Timothee Cour wrote:
>
>> that's not DRY: in my use case, a group of functions use certain imports, it would be annoying and not DRY to do that. What I suggest (allowing {} grouping at module scope) seems simple and intuitive; any reason it can't be done?
>>
>
> How do you ensure that the imports are limited to your {} scope, but your functions are not, without a finnicky special case for how scopes work?
>
granted, that's not ideal. How about the other points I mentioned?
void fun(){
version=A;
version(none):
}
|
August 18, 2013 Re: scoped imports | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | On Sunday, 18 August 2013 at 09:52:29 UTC, Timothee Cour wrote:
> On Sun, Aug 18, 2013 at 2:31 AM, Joseph Rushton Wakeling <
> joseph.wakeling@webdrake.net> wrote:
>
>> On Sunday, 18 August 2013 at 01:33:51 UTC, Timothee Cour wrote:
> granted, that's not ideal. How about the other points I mentioned?
> void fun(){
> version=A;
> version(none):
> }
Not sure I understand what you're trying to achieve there. But as an alternative to function-local import, why not split your module into a package, with submodules mymodule.bardependent and mymodule.nonbardependent ... ?
|
August 18, 2013 Re: scoped imports | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joseph Rushton Wakeling | On Sunday, 18 August 2013 at 14:52:04 UTC, Joseph Rushton Wakeling wrote:
> On Sunday, 18 August 2013 at 09:52:29 UTC, Timothee Cour wrote:
>> On Sun, Aug 18, 2013 at 2:31 AM, Joseph Rushton Wakeling <
>> joseph.wakeling@webdrake.net> wrote:
>>
>>> On Sunday, 18 August 2013 at 01:33:51 UTC, Timothee Cour wrote:
>> granted, that's not ideal. How about the other points I mentioned?
>> void fun(){
>> version=A;
>> version(none):
>> }
>
> Not sure I understand what you're trying to achieve there. But as an alternative to function-local import, why not split your module into a package, with submodules mymodule.bardependent and mymodule.nonbardependent ... ?
Related: is it possible to pack several modules/submodules in a single file? Or do you necessarily have to split them up?
|
August 19, 2013 Re: scoped imports | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joseph Rushton Wakeling Attachments:
| On Sun, Aug 18, 2013 at 7:52 AM, Joseph Rushton Wakeling < joseph.wakeling@webdrake.net> wrote: > On Sunday, 18 August 2013 at 09:52:29 UTC, Timothee Cour wrote: > >> On Sun, Aug 18, 2013 at 2:31 AM, Joseph Rushton Wakeling < joseph.wakeling@webdrake.net> wrote: >> >> On Sunday, 18 August 2013 at 01:33:51 UTC, Timothee Cour wrote: >>> >> granted, that's not ideal. How about the other points I mentioned? >> void fun(){ >> version=A; >> version(none): >> } >> > > Not sure I understand what you're trying to achieve there. goal1: avoid polluting global module name space: void fun(){ version=A; //now the code below in fun() scope has version(A) set } goal2: void fun(){ version(none): //all the code below this IN THIS FUNCTION becomes versioned out //(avoids requiring extra {} scope } > But as an alternative to function-local import, why not split your module into a package, with submodules mymodule.bardependent and mymodule.nonbardependent ... ? > |
Copyright © 1999-2021 by the D Language Foundation