October 12, 2008 Re: backporting features to D1 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | On Sun, Oct 12, 2008 at 9:00 AM, Derek Parnell <derek@psych.ward> wrote:
> On Sat, 11 Oct 2008 12:54:47 -0700, Walter Bright wrote:
>
>> bobef wrote:
>>> category 3) will be forced to break their code because
>>> once D2 is declared stable D1 will probably be declared deprecated
>>
>> No, I intend to support D1 as long as there is interest in it.
>
> I'm no longer using D at all. I've lost interest in D1 as D2 looks to be much, much better. However D2 is a currently whirlwind of uncertainty. I'd love to use some parts of Tango but not D1. I like Phobos (but admit it still has too many warts and omissions) but D2 is just not worth my time yet. I tried coding in D2 but a lot of that code is going to need significant rework when the cabal have finalized their deliberations, which look like being at least 12 months away.
So you're saying you'd be interested in a D1 with non-breaking backports? Or are you looking for something even closer to D2, just without the whirlwind?
--bb
| |||
October 12, 2008 Re: backporting features to D1 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | Derek Parnell wrote:
> I tried coding in D2 but a lot of that code is going to need
> significant rework when the cabal have finalized their deliberations,
I doubt that it would be significant. The time I've invested in converting D1 to D2 code has been trivial.
| |||
October 12, 2008 Re: backporting features to D1 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | Derek Parnell wrote:
> On Sat, 11 Oct 2008 12:54:47 -0700, Walter Bright wrote:
>
>> bobef wrote:
>>> category 3) will be forced to break their code because
>>> once D2 is declared stable D1 will probably be declared deprecated
>> No, I intend to support D1 as long as there is interest in it.
>
> I'm no longer using D at all. I've lost interest in D1 as D2 looks to be
> much, much better. However D2 is a currently whirlwind of uncertainty. I'd
> love to use some parts of Tango but not D1. I like Phobos (but admit it
> still has too many warts and omissions) but D2 is just not worth my time
> yet. I tried coding in D2 but a lot of that code is going to need
> significant rework when the cabal have finalized their deliberations, which
> look like being at least 12 months away.
One way or another D2 will have to be done around April, when TDPL comes along.
Andrei
| |||
October 12, 2008 Re: backporting features to D1 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | == Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Derek Parnell wrote:
> > I tried coding in D2 but a lot of that code is going to need significant rework when the cabal have finalized their deliberations,
> I doubt that it would be significant. The time I've invested in converting D1 to D2 code has been trivial.
What, then, do you see as the reason why others have found porting D1 to D2 less trivial? Do you have any advice that might make it easier for others? This is pretty important because I think it's pretty obvious to everyone here that a major reason for the rift between D1 and D2 is Tango, or lack thereof on D2. If everyone found porting D1 to D2 trivial, I assume the Tango port would have been done long ago.
| |||
October 12, 2008 Re: backporting features to D1 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to dsimcha | On Sun, Oct 12, 2008 at 4:49 AM, dsimcha <dsimcha@yahoo.com> wrote:
> What, then, do you see as the reason why others have found porting D1 to D2 less trivial? Do you have any advice that might make it easier for others? This is pretty important because I think it's pretty obvious to everyone here that a major reason for the rift between D1 and D2 is Tango, or lack thereof on D2. If everyone found porting D1 to D2 trivial, I assume the Tango port would have been done long ago.
A lot of the things I've seen is people having issues making codebases compatible with both D1 and D2, which really _is_ a royal pain.
| |||
October 12, 2008 Re: backporting features to D1 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | Bill Baxter wrote: > On Sat, Oct 11, 2008 at 11:07 PM, Christopher Wright <dhasenan@gmail.com> wrote: >> The issue isn't the lack of new features, so much as bugs being labeled >> enhancements and not being fixed in D1. > > Is there anything in that category other than the partial IFTI stuff? > I was thinking there were very few such cases, actually. Hm. I recall complaints relating to that, but no actual instances. My apologies for perpetuating this without substantiating it. >> If you want the new features, you can switch to D2, so I don't see that as a >> problem. (I want the new features, but I'm waiting for Tango support.) > > I see three potential categories of D users: > 1) bleeding edgers who want the latest and greatest -- don't care if > it breaks everything > 2) want the latest stuff -- but don't want it to break my code > 3) want only bug fixes -- also don't want it to break my code 4) I want the latest stuff -- but if there are no advertised changes except bugfixes, I want my code to continue working between releases. I used to use D2 with lots of CTFE and __traits, but I found that a lot of what I was trying to write couldn't be evaluated at compile time. Then there would be a new release, and the stuff I finally managed to get working would all fail. I didn't really care about backwards compatibility other than that. | |||
October 12, 2008 Re: backporting features to D1 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Bill Baxter | On Sun, 12 Oct 2008 09:22:12 +0900, Bill Baxter wrote: >> I'm no longer using D at all. I've lost interest in D1 as D2 looks to be much, much better. > So you're saying you'd be interested in a D1 with non-breaking backports? Or are you looking for something even closer to D2, just without the whirlwind? No, not really. I'm quite happy with the idea that D1 is 'stable' and that D2 is really an enhanced D1, and is still in prototype mode. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell | |||
October 12, 2008 Re: backporting features to D1 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Sat, 11 Oct 2008 19:55:01 -0500, Andrei Alexandrescu wrote: >> D2 ... look like being at least 12 months away. > One way or another D2 will have to be done around April, when TDPL comes along. Unless TDPL is delayed ;-) -- Derek Parnell Melbourne, Australia skype: derek.j.parnell | |||
October 12, 2008 Re: backporting features to D1 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Sat, 11 Oct 2008 18:21:38 -0700, Walter Bright wrote: > Derek Parnell wrote: >> I tried coding in D2 but a lot of that code is going to need significant rework when the cabal have finalized their deliberations, > > I doubt that it would be significant. The time I've invested in converting D1 to D2 code has been trivial. Ok, that's fine but my experience differs. Converting D1 code to D2 was a very tedious exercise. The main problem, which was to be expected really, was that D2 specification kept changing. So now I'm waiting for a stable D2 before doing anything more. Another problem was trying to have the same codebase support both D1 and D2 - that makes it filled with the silly string mixin workaround, which is plain butt ugly. version(D_Version2) { mixin( `<<some D2 specific code>>` ); } else { <<some D1 equivalent>> } -- Derek Parnell Melbourne, Australia skype: derek.j.parnell | |||
October 12, 2008 Re: backporting features to D1 | ||||
|---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | Derek Parnell wrote:
> Another problem was trying to have the same codebase support both D1 and D2
> - that makes it filled with the silly string mixin workaround, which is
> plain butt ugly.
I understand that's a problem. I don't think that solving it is compatible with the goal of separate lexing, parsing, and semantic analysis passes. That leaves a couple of options:
1. What I do is have two separate code bases for D1 and D2 code, and use the unix program "meld" to manually do a merge now and then. meld makes this quick and easy. I also use meld to help keep the compiler sources in sync.
2. Use an external text processing facility to generate the two source code versions. This is what I do with the D documentation - they use Ddoc macros to generate each custom version.
| |||
Copyright © 1999-2021 by the D Language Foundation
Permalink
Reply