Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
Then I have the function right there with all versioned
implementations. To me that seems better than Phobos' existing style
of version'ing large portions of code, which inevitably results in
duplicating a lot of the functionality in two places.
I wouldn't consider Phobos to be an exemplary example of how to do
versioning, though it should be. I think much of it, like std.file,
should be split off into os-dependent "personality" modules, much like
the os api modules have been.
That would exacerbate code duplication. Consider:
version(Windows) void[] read(in char[] name)
{
...
}
version(Posix) void[] read(in char[] name)
{
...
}
S readText(S = string)(in char[] name)
{
...
}
In my approach they are laid as you see them, which I find very
well-organized.
There is no duplication in:
============ std.file =======================
version (Posix) import std.file.posix;
version (Windows) import std.file.windows;
/* code common to both goes here, like readText() */
=============================================
that is not also in the layout you described.
But there's no hard and fast rule here, and since you are doing the
actual work, I defer to your judgment on those cases.
In your approach you'd define several files each
specialized for an OS, which would duplicate readText, or put readText
into a common file and have it include platform-specific files. Both
solutions are unnecessarily complicated to the simple and clear code above.
While individual details vary, having personality modules for an os
offers some nice advantages:
1. It's pretty clear what is happening for each system.
2. An expert on OSA can work on the OSA implementation without risking
breaking the OSB implementation for which he had no expertise.
3. By looking at which files changed, you can tell which OS support got
updated and which didn't.
4. Porting to a new platform is easier as you've got a list of
personality modules that need to be created, rather than version
statements threaded through the file contents.
5. The "else" clause in OS version statements tend to be wrong when
porting to a new system, meaning that each version has to be gone
through manually - overlooking one doesn't always create an obvious error.
I think the std.core.sys.* modules illustrate the advantages nicely,
especially considering the former kludge-fest bug-ridden way it was
done. The core.stdc.stdio still needs some work in this regard, however.
