View mode: basic / threaded / horizontal-split · Log in · Help
November 29, 2006
Re: minwin
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
Re: minwin
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
Re: minwin
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
Re: minwin
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
Re: minwin
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
Re: minwin
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
Re: minwin
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
Re: minwin
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
Re: minwin
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
Re: minwin
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.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home