www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Versioning in D

reply Sha Chancellor <schancel pacific.net> writes:
I was looking through the versioning examples on the specification.   I 
don't see any examples of an expression.

IE:  
version( API > 4 ) 
{
    ... Something supported in great than version 4 of the API
} else version ( API > 2 ) {
    ... Something supported in great than version 2 of the API
} else {
   ... Some code that only works on really old API versions..
}

Is this supported?  And can imports declare version identifiers?
Jul 23 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Sha Chancellor wrote:
 I was looking through the versioning examples on the specification.   I 
 don't see any examples of an expression.
 
 IE:  
 version( API > 4 ) 
 {
     ... Something supported in great than version 4 of the API
 } else version ( API > 2 ) {
     ... Something supported in great than version 2 of the API
 } else {
    ... Some code that only works on really old API versions..
 }
 
 Is this supported?  And can imports declare version identifiers?

Unfortunately, comparison operators don't work with version (at least they didn't last time I tried it). For now, we'd have to do messy stuff like this... version(API_1) version = API_Not_Supported; version(API_2) version = API_Not_Supported; version(API_3) version = API_Not_Supported; version(API_4) version = API_Supported; version(API_5) version = API_Supported; version(API_6) version = API_Supported; version(API_Not_Supported) { static assert(0); } version(API_Supported) { // ... } As to your other question, I think imports can declare version identifiers with the "version = Whatever;" syntax, but I don't think I've ever tried it. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Jul 23 2004
parent reply Sha Chancellor <schancel pacific.net> writes:
Maybe we could talk walter into it.. =/  I _really_ don't like the method you
proposed.  No offence, it just looks kludgy. It makes you repeat code for
versions which may have compatible code: 

IE:

version( API_2 ) {
CODE
} else version( API_3 ) {
SAME code
} else 
{
SOME CODE FOR OLD VERSION, which would still get processed on API_4, not just
API_1, which is definately not desired.
}

Walter?  Comments?  


In article <cds3cd$2pva$1 digitaldaemon.com>, J C Calvarese says...
Sha Chancellor wrote:
 I was looking through the versioning examples on the specification.   I 
 don't see any examples of an expression.
 
 IE:  
 version( API > 4 ) 
 {
     ... Something supported in great than version 4 of the API
 } else version ( API > 2 ) {
     ... Something supported in great than version 2 of the API
 } else {
    ... Some code that only works on really old API versions..
 }
 
 Is this supported?  And can imports declare version identifiers?

Unfortunately, comparison operators don't work with version (at least they didn't last time I tried it). For now, we'd have to do messy stuff like this... version(API_1) version = API_Not_Supported; version(API_2) version = API_Not_Supported; version(API_3) version = API_Not_Supported; version(API_4) version = API_Supported; version(API_5) version = API_Supported; version(API_6) version = API_Supported; version(API_Not_Supported) { static assert(0); } version(API_Supported) { // ... } As to your other question, I think imports can declare version identifiers with the "version = Whatever;" syntax, but I don't think I've ever tried it. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/

Jul 23 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
Sha Chancellor wrote:
 Maybe we could talk walter into it.. =/  I _really_ don't like the method you
 proposed.  No offence, it just looks kludgy. It makes you repeat code for
 versions which may have compatible code: 

Yep. It's a definitely a kludge. I complained about the lack comparison operators in version a long time ago. I think Walter replied to it, but it was more "maybe someday" than "oh, I'll get right on that." I don't recall anyone bringing up this issue recently. I've become resigned to the reality that we'll probably have to make it work the way it is. Kludgy, yes. Impossible, I don't think so. Maybe D 2.0 will have some cool new versioning facilities. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Jul 23 2004
parent reply Sha Chancellor <schancel pacific.net> writes:
In article <cdsae0$2vtc$1 digitaldaemon.com>, J C Calvarese says...
Sha Chancellor wrote:
 Maybe we could talk walter into it.. =/  I _really_ don't like the method you
 proposed.  No offence, it just looks kludgy. It makes you repeat code for
 versions which may have compatible code: 

Yep. It's a definitely a kludge. I complained about the lack comparison operators in version a long time ago. I think Walter replied to it, but it was more "maybe someday" than "oh, I'll get right on that." I don't recall anyone bringing up this issue recently. I've become resigned to the reality that we'll probably have to make it work the way it is. Kludgy, yes. Impossible, I don't think so. Maybe D 2.0 will have some cool new versioning facilities.

I would think that this is a rather important feature. Maybe we should tie walter up and force him to code :) Does he add features if we donate funds toward it?
Jul 23 2004
parent J C Calvarese <jcc7 cox.net> writes:
Sha Chancellor wrote:
 In article <cdsae0$2vtc$1 digitaldaemon.com>, J C Calvarese says...
 
Sha Chancellor wrote:

Maybe we could talk walter into it.. =/  I _really_ don't like the method you
proposed.  No offence, it just looks kludgy. It makes you repeat code for
versions which may have compatible code: 

Yep. It's a definitely a kludge. I complained about the lack comparison operators in version a long time ago. I think Walter replied to it, but it was more "maybe someday" than


Perhaps the "maybe someday"-ish response was in my head. I think I found the old thread that I was remembering. Here's where is starts: D/18144 I just now looked at the old thread. It seemed to be a Walter-vs-everyone else thread where most posters complained that version isn't as flexible as #define. (My old post is in there somewhere, but it's neither the most important post in the thread nor as cool as I remember it.)
"oh, I'll get right on that." I don't recall anyone bringing up this 
issue recently. I've become resigned to the reality that we'll probably 
have to make it work the way it is. Kludgy, yes. Impossible, I don't 
think so.

Maybe D 2.0 will have some cool new versioning facilities.

I would think that this is a rather important feature. Maybe we should tie walter up and force him to code :) Does he add features if we donate funds toward it?

LOL. I don't think Walter can be bought. I think he enjoys working for himself too much. -- Justin (a/k/a jcc7) http://jcc_7.tripod.com/d/
Jul 23 2004
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Sha Chancellor wrote:
 I was looking through the versioning examples on the specification.   I 
 don't see any examples of an expression.
 
 IE:  
 version( API > 4 ) 
 {
     ... Something supported in great than version 4 of the API
 } else version ( API > 2 ) {
     ... Something supported in great than version 2 of the API
 } else {
    ... Some code that only works on really old API versions..
 }
 
 Is this supported?  And can imports declare version identifiers?

It is supported through the back door. version = 4; or -version=4 on the commandline will do version (3) { // left out } version (4) { // compiled } version (5) { // compiled } There is also the possibility for an else clause: version (4) { // compiled } else { // left out } The docs say: -version=level compile in version code >= level Note that for -debug=level compile in debug code <= level Lars Ivar Igesund
Jul 24 2004
parent reply Sha Chancellor <schancel pacific.net> writes:
In article <cdt152$ip1$1 digitaldaemon.com>,
 Lars Ivar Igesund <larsivar igesund.net> wrote:

 It is supported through the back door.
 
 version = 4; or -version=4 on the commandline will do
 
 version (3) {
    // left out
 }
 
 version (4) {
    // compiled
 }
 
 version (5) {
    // compiled
 }
 
 There is also the possibility for an else clause:
 
 version (4) {
    // compiled
 }
 else {
    // left out
 }
 
 The docs say:
 
 -version=level
    compile in version code >= level
 
 Note that for
 -debug=level
    compile in debug code <= level
 
 
 Lars Ivar Igesund

This doesn't fix the problem I described. For example: In MacOS 9 and below there are different versions of the API as declared in defines. For some cross-version compilation you need #if API_VERSION < 3 #endif crap going on. But there is different version numbers for different APIs. While this might work if i only ever used one module. It doesn't fix the problem. It's also flawed in another way: Maybe version(4) {} and version (5) {} code are mutually exclusive but you want to compile version 4? How is that accomplished.
Jul 24 2004
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Sha Chancellor wrote:


The docs say:

-version=level
   compile in version code >= level

Note that for
-debug=level
   compile in debug code <= level


Lars Ivar Igesund

This doesn't fix the problem I described. For example: In MacOS 9 and below there are different versions of the API as declared in defines. For some cross-version compilation you need #if API_VERSION < 3 #endif crap going on. But there is different version numbers for different APIs. While this might work if i only ever used one module. It doesn't fix the problem. It's also flawed in another way: Maybe version(4) {} and version (5) {} code are mutually exclusive but you want to compile version 4? How is that accomplished.

Well, note that I switched debug and version above :). This means that specifying version=4 will compile in version 4. Version=5 will compile in both (as is logical). Alas, AFAICS, only one version integer can be used in one compilation. Thus you probably need to use string identifiers and nested version statments for the more complex stuff, but this might not be enough either, at least not without doubling up the code. The best (and just a little bit more complex) solution would probably be to be able to specify integers like this (or similar) -version[ONE_API]=4 -version[OTHER_API]=7 and then have expressions that can use ONE_API and OTHER_API like you sketched in your first post. Lars Ivar Igesund
Jul 24 2004