www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Proposal: forward compatibility

reply Jason House <jason.james.house gmail.com> writes:
D is an evolving language that does not restrict itself by requiring backwards
compatibility. Instead I propose that D adopt forward compatibility... 

Specifically, allow D1 code to accept D2 code without doing extra
functionality. In D1, his would allow defining constants to be declared with
either const or invariant, object invariants to allow parenthesis,  and
ignoring transitive const elements of type declarations.

The goal is to not change the behavior of existing D1 code, but to accept
previously invalid D1 code. This should make the job of maintaining a dual code
base much easier.
Sep 04 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
I'm all for anything that makes D1, or the combo of D1 & D2, more usable.

--bb

On Fri, Sep 5, 2008 at 2:57 PM, Jason House <jason.james.house gmail.com> wrote:

 D is an evolving language that does not restrict itself by requiring backwards
compatibility. Instead I propose that D adopt forward compatibility...

 Specifically, allow D1 code to accept D2 code without doing extra
functionality. In D1, his would allow defining constants to be declared with
either const or invariant, object invariants to allow parenthesis,  and
ignoring transitive const elements of type declarations.

 The goal is to not change the behavior of existing D1 code, but to accept
previously invalid D1 code. This should make the job of maintaining a dual code
base much easier.
Sep 05 2008
parent Fawzi Mohamed <fmohamed mac.com> writes:
On 2008-09-06 03:00:37 +0200, "Bill Baxter" <wbaxter gmail.com> said:


 I'm all for anything that makes D1, or the combo of D1 & D2, more usable.
 
 --bb
 
 On Fri, Sep 5, 2008 at 2:57 PM, Jason House 
 <jason.james.house gmail.com> wrote:

 D is an evolving language that does not restrict itself by requiring 
 backwards compatibility. Instead I propose that D adopt forward 
 compatibility...
 
 Specifically, allow D1 code to accept D2 code without doing extra 
 functionality. In D1, his would allow defining constants to be declared 
 with either const or invariant, object invariants to allow parenthesis, 
  and ignoring transitive const elements of type declarations.
 
 The goal is to not change the behavior of existing D1 code, but to 
 accept previously invalid D1 code. This should make the job of 
 maintaining a dual code base much easier.




I thnk that it would be very good for tango (and phobos?), as it would 
mean that a big part of the code (and bugfixes,...) might be shared 
between D1.0 and D2.0.
As these libraries will need to be supported in D1.0 for more time (as 
long a important projects use D1.0).

For smaller things... well the developer will probably focus just on 
the language they are using, which means the one of the base library.

Easing the transition is to D2.0 for big projects is worthwhile I think.

Fawzi
Sep 06 2008
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 05 Sep 2008 09:57:40 +0400, Jason House  
<jason.james.house gmail.com> wrote:


 D is an evolving language that does not restrict itself by requiring  
 backwards compatibility. Instead I propose that D adopt forward  
 compatibility...

 Specifically, allow D1 code to accept D2 code without doing extra  
 functionality. In D1, his would allow defining constants to be declared  
 with either const or invariant, object invariants to allow parenthesis,   
 and ignoring transitive const elements of type declarations.

 The goal is to not change the behavior of existing D1 code, but to  
 accept previously invalid D1 code. This should make the job of  
 maintaining a dual code base much easier.


I came up with the following constness solution:

First, define a Const!(T) template as follows:

// dconst.d
version (D_Version2) {
     public import dconst2;
} else {
     public import dconst1;
}

//dconst1.d
template Const(T)
{
     alias const T Const;
}

//dconst2.d
template Const(T)
{
     alias const(T) Const;
}

Now you can import dconst.d and use the Const!(T) template in your code do  
define constant objects:

import dconst;

void foo(Const!(Bar) bar)
{
     // ...
}

D1 will ignore constness while D2 will preserve and respect it.

Next, you should add const methods into your classes:

class Node
{
     Node next() {
         return _next;
     }

version (D_Version2) {         // You have to duplicate the code
     const Const!(Node) next()  // when return a reference object in
     {                          // D2 anyway, so that's not a big deal.
         return _next;
     }
}

     void next(Node value) {
         _next = value;
     }

version (D_Version2) {        // However, you don't have to for void and
     const int value() {       // value types, and this is quite a pain now
         return _value;        // (especially for long function bodies).
     }
} else {
     int value() {
         return _value;
     }
}

     void value(int value) {
         _value = value;
     }

     private int _value;
     private Node _next;
}

// Test case:
void test(Const!(Node) node)
{
     Const!(Node) nextNode = node.next;
     if (nextNode !is null) {
         writefln(nextNode.value);
     } else {
         writefln(node.value);
     }
}

So here is my suggestion:
1) there should be something like Const template in Phobos/Tango for D1/D2  
compatibility. It is very simple yet clean and it is as easy to write  
Const!(T) as const(T).

2) D1 should swallow and ignore const modifier for member functions so  
that there would be no need for body duplication:

// Same for D1 *and* D2 (although meaning is slightly different)
// no need for version (D_Version2) { ... } else { ... } anymore

class Node {
     int value() const {
         return _value;
     }
}

This would allow much easier D1/D2 migration without massive language  
changes.

What do you think?
Sep 06 2008
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
A quote wrote some time ago:

"Sean Kelly" wrote

 Bill Baxter wrote:

 Sean Kelly wrote:

 dsimcha wrote:

 On another note, anyone have any idea when/if Tango for D2, and 
 Tangobos for Tangofor D2, will be available?  There are things I like  
 and dislike aboutboth Tangoand Phobos, and I really wish I could mix  
 and match modules from themwithoutgiving up my D2 features.  For  
 example, I like Phobos's much simpler IOAPI, less"OO everywhere" look  
 and feel and "simple operations should be simple"mentality,but I like  
 Tango's extra math and threading stuff and richer featureset in 
 general.  Also, I've written a decent amount of Phobos code that I 
 don't feel likeporting.


 There's no timeframe for D2 support at the moment.  I may look into at 
 least having the runtime be cross-compatible, but porting the user code 
 would require changes in structure / coding strategy that I can't see 
 anyone wanting to make.


 It seems to me that some people do actually like D2 and aren't using 
 Tango precisely because there's no D2 support.  So who knows, maybe 
 you'll find there's a new crop of D2/Tango volunteers that show up once 
 the ball gets rolling.  Steven S. for one, perhaps.


 Yup.  There has been enough interest that I think it's worth getting the 
 runtime working at least.  The only real obstacle to that right now is 
 time.  The runtime uses the standard C, Posix, and Win32 packages for 
 various things and none of these are D2 compatible at the moment.  So the 
 sticking point is really that I need to find the time to go through the 
 standard C and Posix specs and add "in" to all the function parameters 
 that are const in the C APIs.  I should have left /*const*/ as a 
 placeholder when I created the modules but... oh well.  Live and learn.


Not /*const*/ but Const!()
Sep 06 2008
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Denis Koroskin wrote:


 On Fri, 05 Sep 2008 09:57:40 +0400, Jason House
 <jason.james.house gmail.com> wrote:
 

 D is an evolving language that does not restrict itself by requiring
 backwards compatibility. Instead I propose that D adopt forward
 compatibility...

 Specifically, allow D1 code to accept D2 code without doing extra
 functionality. In D1, his would allow defining constants to be declared
 with either const or invariant, object invariants to allow parenthesis,
 and ignoring transitive const elements of type declarations.

 The goal is to not change the behavior of existing D1 code, but to
 accept previously invalid D1 code. This should make the job of
 maintaining a dual code base much easier.


 
 I came up with the following constness solution:
 
 First, define a Const!(T) template as follows:
 
 ...
 
 This would allow much easier D1/D2 migration without massive language
 changes.
 
 What do you think?


I was worried that making a D1 compiler accept const in types declarations
would be a killer of the forward compatibility idea.  I think what you
propose for const type handling is a reasonable compromise.  It'd be easy
enough to write a Const!(T) and Invariant!(T) template.

I like how all the response to my proposal has been positive.  Sadly, it
can't go anywhere unless Walter likes the idea and he has yet to respond.
Sep 06 2008