Version declaration proposal
Don
nospam at nospam.com
Wed Feb 11 00:01:29 PST 2009
I think I have a solution to the versioning problems.
My belief is that version statements are fine, and Walter's 'rats nest'
argument is valid. Instead, I believe that version declarations limited
to "version = XXX;" are too weak. They also have syntax which is subtly
different to the rest of the language.
(version = A; version = B; looks as though you're changing the value of
the 'version' variable).
My proposal is therefore:
--------
* Keep version statements unchanged.
* Change version declarations to make them almost identical to bool
declarations:
version _versionidentifier_ = _versionexpression_;
where _versionexpression_ is a boolean expression involving only true,
false, or other version identifiers, and standard boolean operators.
* If, in addition, we allow:
version _versionidentifier_ = extern;
for versions which are supplied from the command line, it can then
become illegal to have a version statement referring to an undeclared
version identifier.
(Any version identifier beginning with D_ is implicitly an "= extern;"
identifier, so does not need to be declared).
Another possibile syntax is extern version _versionidentifier_; to make
the syntax identical to normal declarations.
--------
This addresses a few problems:
* typos in version identifiers.
* Comprehensibility. When you see something like:
version (UseLargeSize) {
}
you have no idea if that version identifier declaration is buried in the
code somewhere, or whether it is a command-line option. It could even be
both!
* The effect of this would be to encourage you to create a block of
version declarations at the start of the module, where they are easy to
analyze and refactor.
* A lint tool could even enforce this, by disallowing any version
declarations after the first normal declaration is encountered.
I believe this would reduce rats-nest versioning, and also eliminate the
rats-nesting we have in version declarations right now.
Is there anything wrong with it?
More information about the Digitalmars-d
mailing list