November 29, 2006
Tomas Lindquist Olsen wrote:
> version(Windows || linux)
> {
>     ...
> }
> else
> {
>     ...
> }
> 
> is clearer IMHO.

That is certainly seductive and it's hard to see what's wrong with it. But I've seen what it inevitably leads to - an ugly, incomprehensible mess that is invariably wrong. It's often so bad that I have to run the preprocessor just to figure out which pieces of the code are actually being compiled! I haven't seen one yet that couldn't stand being reevaluated.

If you find wanting && and || and ?: and ! in the versions, I suggest one the following:

1) reevaluate just what feature it is you're testing for, and create a version identifier for that feature.

2) abstract the version differences away in a separate module.

Sure, it requires a little more work and a little more thought. But I think it's worth it, it's certainly been so when I've used that approach.
November 29, 2006
Bill Baxter wrote:
> Here's wxWidgets version macro for checking the version of wxWidgets you're compiling with.  It should be possible to get the same effect in D somehow:
> 
> /*  check if the current version is at least major.minor.release */
> #define wxCHECK_VERSION(major,minor,release) \
>     (wxMAJOR_VERSION > (major) || \
>     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION > (minor)) || \
>     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION == (minor) && wxRELEASE_NUMBER >= (release)))

To ask the obvious dumb question, why? If I was to see such, I'd wonder what purpose wxCHECK_VERSION was being used for. I presume it is to enable/disable certain things.

I suggest instead to either:

1) create version identifiers for those "certain things" like wxFEATURE_FOO_IS_WORKING

2) create an api for those features and abstract them into other modules

3) wxVERSION_NUMER already combines the values into one integer. Use that integer instead as the overall version number.
November 29, 2006
Walter Bright wrote:
> Bill Baxter wrote:
>> Here's wxWidgets version macro for checking the version of wxWidgets you're compiling with.  It should be possible to get the same effect in D somehow:
>>
>> /*  check if the current version is at least major.minor.release */
>> #define wxCHECK_VERSION(major,minor,release) \
>>     (wxMAJOR_VERSION > (major) || \
>>     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION > (minor)) || \
>>     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION == (minor) && wxRELEASE_NUMBER >= (release)))
> 
> To ask the obvious dumb question, why? If I was to see such, I'd wonder what purpose wxCHECK_VERSION was being used for. I presume it is to enable/disable certain things.
> 
> I suggest instead to either:
> 
> 1) create version identifiers for those "certain things" like wxFEATURE_FOO_IS_WORKING

That's great if the wx developers put that in for me, but if they didn't then the wx release number is the only info you have to determine if FEATURE_FOO_IS_WORKING.  So you'll end up with basically this in your "version features" module:

static if(wxCHECK_VERSION > 20603) {
   version = FEATURE_FOO_IS_WORKING
}

The need for checking against a version didn't go away, it just moved into the module.

If that's the way one is supposed to use 'version' then I'm ok doing that.  Just seems like both kinds of checks are about versions, so it should all be in a version() check, rather than some things static if(), some things version().

> 
> 2) create an api for those features and abstract them into other modules
> 
> 3) wxVERSION_NUMER already combines the values into one integer. Use that integer instead as the overall version number.

--bb
November 29, 2006
Walter Bright wrote:

>> So are you saying that we should *not* write
>> "version(whatever) {} else" for D's #ifndef ?
> 
> No, I'm saying one should not have properties that contain a negative, such as NOTMAIN or NOALIAS.

Agreed. It's better to pick the positive - if possible.

I just think that is plusungood to not be able to express
my thoughts, just because it is against "good manners"...
But I guess I'm just too rooted in the Oldspeak languages.

I do have the feeling this is just "!is" all over again,
but I don't think it is meaningful to discuss it further.
If and when D gets !versions, it's easy to change "{} else".

--anders
November 29, 2006
Bill Baxter wrote:

> The need for checking against a version didn't go away, it just moved into the module.

Only problem is that you cannot import version statements from modules.

So all those version statements need to move to the command line, or to
an external tool like bu[il]d in order to have something like autoconf.

--anders
November 29, 2006
Bill Baxter wrote:
> Walter Bright wrote:
>> Bill Baxter wrote:
>>> Here's wxWidgets version macro for checking the version of wxWidgets you're compiling with.  It should be possible to get the same effect in D somehow:
>>>
>>> /*  check if the current version is at least major.minor.release */
>>> #define wxCHECK_VERSION(major,minor,release) \
>>>     (wxMAJOR_VERSION > (major) || \
>>>     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION > (minor)) || \
>>>     (wxMAJOR_VERSION == (major) && wxMINOR_VERSION == (minor) && wxRELEASE_NUMBER >= (release)))
>>
>> To ask the obvious dumb question, why? If I was to see such, I'd wonder what purpose wxCHECK_VERSION was being used for. I presume it is to enable/disable certain things.
>>
>> I suggest instead to either:
>>
>> 1) create version identifiers for those "certain things" like wxFEATURE_FOO_IS_WORKING
> 
> That's great if the wx developers put that in for me, but if they didn't then the wx release number is the only info you have to determine if FEATURE_FOO_IS_WORKING.  So you'll end up with basically this in your "version features" module:
> 
> static if(wxCHECK_VERSION > 20603) {
>    version = FEATURE_FOO_IS_WORKING
> }
> 
> The need for checking against a version didn't go away, it just moved into the module.
> 
> If that's the way one is supposed to use 'version' then I'm ok doing that.  Just seems like both kinds of checks are about versions, so it should all be in a version() check, rather than some things static if(), some things version().
> 
>>
>> 2) create an api for those features and abstract them into other modules
>>
>> 3) wxVERSION_NUMER already combines the values into one integer. Use that integer instead as the overall version number.
> 
> --bb

One thing I like about D is the opportunity to evaluate past mechanisms to see if they're the 'right' way of doing things.  Something about the use of specific feature flags rather than generic version number matching feels cleaner.  I do recognize that it makes porting of some existing blocks of code one notch harder.

Later,
Brad
November 29, 2006
On Wed, 29 Nov 2006 03:26:58 -0500, Anders F Björklund <afb@algonet.se> wrote:

> Bill Baxter wrote:
>
>> The need for checking against a version didn't go away, it just moved into the module.
>
> Only problem is that you cannot import version statements from modules.
>
> So all those version statements need to move to the command line, or to
> an external tool like bu[il]d in order to have something like autoconf.
>
> --anders

I like how D simplified this. It makes it much easier to do a general parse of a source file without having to follow imports (which can be a pain - e.g. several import dirs).

This is also why I like how `static if` and version are for different purposes and `static if` should not work at the module level.
November 29, 2006
Chris Miller wrote:

> I like how D simplified this. It makes it much easier to do a general  parse of a source file without having to follow imports (which can be a  pain - e.g. several import dirs).

Simpler for the parser, I guess. But harder for the user, unfortunately.
(since you have learn and make changes with more than one tool/language)
But once one gets the build system in place, it should be all good...
(i.e. instead of doing a config.h file, it can generate a commandline)

Probably only affects us weirdos not using "Windows" or "linux" anyway.

--anders
November 29, 2006
Tomas Lindquist Olsen wrote:

> For those that dont read the dsource forums, Brad has set up a SVN repository [1] and Trac environment [2] for MinWin and given me admin rights.
> 
> I have committed the version I posted to SVN with Anders's patch applied.
> 
> Lets get MinWin back on track :)

If you really want to try minwin out running on Mac OS X,
you first need Motif/LessTif and X11. And some hack like
mine: http://www.algonet.se/~afb/d/minwin-darwin.patch
(or you'll need to get the Imlib library going yourself)

Then (I guess) it should be something along the lines of:
bud @motif.brf

If you have MacPorts installed, you would probably prefer
using the GTK+ for X11 port from there instead of Motif...
And if you're really bored, you could try a Carbon port ?
(see http://developer.apple.com/referencelibrary/Carbon/)

--anders
November 29, 2006
Walter Bright wrote:
> Tomas Lindquist Olsen wrote:
> 
>> version(Windows || linux)
>> {
>>     ...
>> }
>> else
>> {
>>     ...
>> }
>>
>> is clearer IMHO.
> 
> 
> That is certainly seductive and it's hard to see what's wrong with it. But I've seen what it inevitably leads to - an ugly, incomprehensible mess that is invariably wrong. It's often so bad that I have to run the preprocessor just to figure out which pieces of the code are actually being compiled! I haven't seen one yet that couldn't stand being reevaluated.
> 
> If you find wanting && and || and ?: and ! in the versions, I suggest one the following:
> 
> 1) reevaluate just what feature it is you're testing for, and create a version identifier for that feature.
> 
> 2) abstract the version differences away in a separate module.
> 
> Sure, it requires a little more work and a little more thought. But I think it's worth it, it's certainly been so when I've used that approach.

Sometimes a common problem suggests a solution so that everybody in the audience invents more or less the same thing. When it doesn't seem to have immediate downsides, there'll be unanimous demand for it.

If the man on the stage doesn't shoot down the solution vigorously enough, there will eventually be a riot demanding implementation.

At the end of the day, only historians will eventually sort out who was right each time.

---

This compiling conditionals issue, IMHO, is what Walter really has been doing all his life. And such Experience is invaluable when the downsides are not obvious enough to even seasoned programmers. In one sense, that's the whole point of demanding experience when hiring people.