August 19, 2013 Re: scoped imports | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timothee Cour | On Monday, 19 August 2013 at 01:16:44 UTC, Timothee Cour wrote:
> 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
> }
I honestly think that you are spending far too much mental effort in pursuit of complex, finnicky solutions for issues that can be dealt with much better by other means.
If you're getting namespace clashes because one set of functions is dependent on foo.stuff and others are dependent on bar.stuff, surely the simplest way to avoid it is to place them in different modules -- which can then be grouped into a package if needed. What's wrong with this approach?
|
August 19, 2013 Re: scoped imports | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joseph Rushton Wakeling | On Monday, August 19, 2013 04:36:37 Joseph Rushton Wakeling wrote:
> On Monday, 19 August 2013 at 01:16:44 UTC, Timothee Cour wrote:
> > 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
> > }
>
> I honestly think that you are spending far too much mental effort in pursuit of complex, finnicky solutions for issues that can be dealt with much better by other means.
>
> If you're getting namespace clashes because one set of functions is dependent on foo.stuff and others are dependent on bar.stuff, surely the simplest way to avoid it is to place them in different modules -- which can then be grouped into a package if needed. What's wrong with this approach?
I'd also chime in that version should generally be used for system stuff (like Posix or X86_64), and it's usually a bad idea to be setting version identifiers anywhere other than the command line. Version identifiers just aren't designed for that, particularly as setting them in a module can't affect other modules, seriously limiting their applicability if they're not set on the command line. If you have local stuff that you want to turn on or off, it's probabyl better to use enums, variables, is expressions, or something similar inside of static ifs rather than using version blocks. It's also much easier to control the scope of variables if want to affect the static ifs that way.
- Jonathan M Davis
|
Copyright © 1999-2021 by the D Language Foundation