Walter Bright wrote:
Andrei Alexandrescu wrote:
In my approach they are laid as you see them, which I find very
well-organized.
There is no duplication in:
[snip]
I said there's either duplication or complication.
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.
Great, thanks!
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.
Not clear to me. It's happened to me more than once to fix a function
without knowing that it's version()ed (your fault: you didn't indent it)
and that there's a corresponding Windows function some miles away.
To me it's much clearer to have all specializations of a given piece of
functionality close to one another. They'd naturally tend to converge,
not diverge.
2. An expert on OSA can work on the OSA implementation without risking
breaking the OSB implementation for which he had no expertise.
Ok.
3. By looking at which files changed, you can tell which OS support got
updated and which didn't.
I never look... :o)
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.
No. This is where your point gets destroyed. Unittests should dictate
what must be done for porting to a new platform. Your approach forces
either duplicate unittests, or collector files that add clutter.
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 try to avoid else. I want to implement setenv on Windows, I prefix it
with Windows. I want to implement it on Posix, I prefix it with Posix.
Then I write one unittest. Then when a new OS comes, setenv won't be
found so the unittest can't run. Problem solved *much* better.
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.
I don't know about that.
Andrei
