Bill Baxter wrote:
> On Mon, Jul 13, 2009 at 10:05 PM, Walter
> Bright<newshound1@digitalmars.com> wrote:
>> Julian Salazar wrote:
>> It's been rehashed here several times (not to rag on you, just to point out
>> that it isn't something that's been overlooked). To sum up, I've worked a
>> lot with both styles - #ifdef, and separating dependencies into independent
>> modules. The latter works a lot better. I know it's hard to believe if
>> you're used to the #ifdef style. I've been doing some work to remove
>> #ifdef's from the dmd compiler source, and the results so far have been very
>> satisfactory.
> 
> But from where I sit it looked like Walter didn't really convince
> anyone.  To me this seems like a point where D is overly patronizing,
> to use the phrase from a recent post.

FWIW I've recently experimented in Phobos with function-level versioning, e.g.:

version(Posix) void setenv(in char[] name, in char[] value, bool overwrite)
{
    ...
}

version(Windows) void setenv(in char[] name, in char[] value, bool overwrite)
{
    ...
}

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.

One other thing I like about the approach above is that it does not necessitate an extra level of indentation, and it doesn't make you feel guilty for not adding it. I cringe whenever I see at the top level:

version (something)
{
non_indented_stuff

more_non_indented_stuff

etc
}



Andrei

I appreciate the reply, and I guess that your point about separating dependencies into different modules is a good form of version management. I'll still be using the version(x86) asm {...} else version(x86_64) asm {...} syntax for a while though. But I'm done arguing that point.

My final question is just about how I would go about contributing to the Inline Assembler specification. I found that you generate the language spec from the trunk/docsrc folder on the Phobos SVN repo on dsource.org. So, am I right to think that I could just download the docsrc folder, edit the iasm.dd file (and use the linux.mak file to view it in .html) and submit it here for review? 

Bill Baxter wrote:
> But from where I sit it looked like Walter didn't really convince
> anyone.  To me this seems like a point where D is overly patronizing,
> to use the phrase from a recent post.

You could argue that, but it also took a long time to convince many about the merit of const and immutable. I understand that C style versioning is so seductive, it's very hard to see what's wrong with it.

(For another reason against such, I could send you some of the source to optlink. It's chock full of line by line versioning, nested versioning, a couple dozen version arguments, it's so bad the only way I can tell what's going on is to compile it then *disassemble* it to see what the code actually is.)

Contrast that with the dmd front end source where I've made a concerted effort (not 100% yet) to remove #ifdef's.

And I didn't even touch on what would have to happen if versioning could slice anywhere - it would have to be done as a separate pre-pass. It couldn't be integrated in to the current one-pass parser, and would do a fine job of screwing up syntax highlighters and pretty-printers much like C's preprocessor can.

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.

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. 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.


Andrei

On Tue, Jul 14, 2009 at 10:01 AM, Walter Bright<newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> But from where I sit it looked like Walter didn't really convince anyone.  To me this seems like a point where D is overly patronizing, to use the phrase from a recent post.
>
> You could argue that, but it also took a long time to convince many about the merit of const and immutable. I understand that C style versioning is so seductive, it's very hard to see what's wrong with it.
>
> (For another reason against such, I could send you some of the source to optlink. It's chock full of line by line versioning, nested versioning, a couple dozen version arguments, it's so bad the only way I can tell what's going on is to compile it then *disassemble* it to see what the code actually is.)
>
> Contrast that with the dmd front end source where I've made a concerted effort (not 100% yet) to remove #ifdef's.
>
> And I didn't even touch on what would have to happen if versioning could slice anywhere - it would have to be done as a separate pre-pass. It couldn't be integrated in to the current one-pass parser, and would do a fine job of screwing up syntax highlighters and pretty-printers much like C's preprocessor can.
>

I wasn't very clear.
I do think you make a convincing argument that in general lots of
micro ifdefs everywhere is not the right approach.
But I remain unconvinced that potential for abuse is a good reason to
disallow finer scale version() statements.  It smacks of the same
patronizing one-size-fits-all attitude of java, where everything has
to be a class because the designers decided that OO==better design.
It just doesn't seem to fit well with the rest of the D attitude of
not getting in the developer's way.

--bb

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.

Bill Baxter wrote:
> I do think you make a convincing argument that in general lots of
> micro ifdefs everywhere is not the right approach.
> But I remain unconvinced that potential for abuse is a good reason to
> disallow finer scale version() statements.

It's where the line between micro and fine is that you disagree with, not the principle?

Julian Salazar wrote:
> My final question is just about how I would go about contributing to the Inline Assembler specification. I found that you generate the language spec from the trunk/docsrc folder on the Phobos SVN repo on dsource.org. So, am I right to think that I could just download the docsrc folder, edit the iasm.dd file (and use the linux.mak file to view it in .html) and submit it here for review?

Right, except that submitting diffs to bugzilla as an enhancement proposal is the best approach. Newsgroups are for transitory discussions.

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