Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
"Walter Bright" wrote
Think of code that is versioned around architecture that would look
horrendous if you have to do version statements that have all
different combinations of stuff. If I have 5 different architectures
to support, I don't want to have to define a module that has 2^5
different version combinations. On top of that, the way versioning
works, you need 2^4 * 5 different statements:
version(A)
{
version = AorB;
version = AorC;
version = AorD;
version = AorE;
version = AorBorC;
version = AorBorD;
// ad nauseum.
}
version(B)
{
// oh fun! let's do it again!!!!
version = AorB;
version = BorC;
version = BorD;
...
}
When I add another architecture, *gasp* I have to double the
statements (to do them now with and without version(F) ), and now I
have to do another 2^5 statements for the version(F) block. Wheee!
But this is clearly the wrong way of cutting the pie. What you need is
define features that are supported by some of the versions. You don't
need to judge in terms of logical operators between versions.
version (A) version = canBeUsedToPickupChicks;
version (C) version = canBeUsedToPickupChicks;
// version (B) no good
There's one slightly irritating issue I've run into with versions
recently. In the spare few instances where I actually need to do
something like this, I like to put everything together so I know at a
glance what's going on. However, versions may not be defined in class
scope, so:
class C
{
version (A) version = useSomeFancyThing;
version (B) version = useSomeFancyThing;
version (useSomeFancyThing)
{
Fancy[1024] fancyPants;
}
}
This is illegal. Kind of a small issue, but I grumbled about it for a
minute or two before I broken down and just duplicated the declaration
for each version. I could have easily put the tests at module scope
before the class declaration, but I wanted everything together.
Sean
