View mode: basic / threaded / horizontal-split · Log in · Help
October 11, 2008
Re: backporting features to D1
Bill Baxter wrote:
> Porting proven, non-breaking D2.0 features to D1.0 would *not* mutate
> D1.0 into D2.0.  Const stuff would never be ported to D1.0, for
> instance because there's really no way to do it without breaking
> existing D1 code.  And since we're talking about porting proven,
> backwards-compatible features, it still means D1.0 is significantly
> more stable than D2.

I agree and would like to see the choice for not moving proven,
backwards-compatible features from the D2-playground into D1-stable
reconsidered. The big, conceptual changes like const/invariant, pure,
shared, closures, ... could not be moved to D1 without breaking existing
code, but a lot of small things could.

There should be much less complaints about getting new features every month
if these features are fully backwards-compatibly and have been tested in D2
for a while. This is particularly true for things like the partial IFTI
improvements that could be considered bugs in D1.

I think some fixes to D1 bugs will prove to be much more troublesome. We
recently applied the patch to 313/314 in LDC and that *did* break some
existing code (by exposing bugs, but still...).
October 11, 2008
Re: back port opDot to D 1.0?
Walter Bright wrote:
> u wrote:
>> I like this feature so much.
>> Is it possible to back port opDot to D 1.0?
> 
> 
> The problem is for every last feature in D 2.0, there's someone who 
> wants that and only that ported to 1.0. If I moved over opDot, what am I 
> going to say to everyone else? I move over their features too, and then 
> D 1.0 becomes 2.0 anyway. I suggest instead just moving to 2.0 <g>.

I think that some consideration should be given to those features which 
make it easier to migrate code from D1 to D2. Especially things which 
make version(D2) {...} impossible in D1 code.
October 11, 2008
Re: backporting features to D1
Bill Baxter wrote:
> I recall a wise man who once said you shouldn't give much weight to
> what people use as excuses for not using your language.  They probably
> aren't going to use it anyway.

The people using it wanted a stable version.
October 12, 2008
Re: backporting features to D1
On Sat, 11 Oct 2008 21:42:27 +0200, Walter Bright  
<newshound1@digitalmars.com> wrote:

> Bill Baxter wrote:
>> I recall a wise man who once said you shouldn't give much weight to
>> what people use as excuses for not using your language.  They probably
>> aren't going to use it anyway.
>
> The people using it wanted a stable version.


I got an idea, what if you backported some stuff from D2 to D1 (obviously  
not the const system) and made those features only available when a switch  
on the command-line was turned on, for example -v1.1? Ought to satisfy  
both camps, the conservatives and the reformers. Whaddaya say?
October 12, 2008
Re: backporting features to D1
Aziz K. wrote:
> I got an idea, what if you backported some stuff from D2 to D1 
> (obviously not the const system) and made those features only available 
> when a switch on the command-line was turned on, for example -v1.1? 
> Ought to satisfy both camps, the conservatives and the reformers. 
> Whaddaya say?

I've dealt with that on C/C++ compilers for years, and it's an unending 
testing and configuration nuisance.
October 12, 2008
Re: backporting features to D1
On Sun, Oct 12, 2008 at 10:56 AM, Walter Bright
<newshound1@digitalmars.com> wrote:
> Aziz K. wrote:
>>
>> I got an idea, what if you backported some stuff from D2 to D1 (obviously
>> not the const system) and made those features only available when a switch
>> on the command-line was turned on, for example -v1.1? Ought to satisfy both
>> camps, the conservatives and the reformers. Whaddaya say?
>
> I've dealt with that on C/C++ compilers for years, and it's an unending
> testing and configuration nuisance.

Python's strategy of introducing new features is the best I've seen by far.
And with that they have made big changes in the language without ever
creating any major split in the user base, as far as I can tell.

--bb
October 12, 2008
Re: backporting features to D1
Bill Baxter wrote:
> Python's strategy of introducing new features is the best I've seen by far.
> And with that they have made big changes in the language without ever
> creating any major split in the user base, as far as I can tell.

Most of the split in the user base is a result of Tango being D1 only 
(which I hope will be resolved shortly).
October 12, 2008
Re: backporting features to D1
On Sun, Oct 12, 2008 at 4:48 AM, Walter Bright
<newshound1@digitalmars.com> wrote:
> Bill Baxter wrote:
>>
>> Python's strategy of introducing new features is the best I've seen by
>> far.
>> And with that they have made big changes in the language without ever
>> creating any major split in the user base, as far as I can tell.
>
> Most of the split in the user base is a result of Tango being D1 only (which
> I hope will be resolved shortly).

Then address the issues of stack vs. heap delegates.
October 12, 2008
Re: backporting features to D1
Jarrett Billingsley wrote:
> On Sun, Oct 12, 2008 at 4:48 AM, Walter Bright
> <newshound1@digitalmars.com> wrote:
>> Bill Baxter wrote:
>>> Python's strategy of introducing new features is the best I've seen by
>>> far.
>>> And with that they have made big changes in the language without ever
>>> creating any major split in the user base, as far as I can tell.
>> Most of the split in the user base is a result of Tango being D1 only (which
>> I hope will be resolved shortly).
> 
> Then address the issues of stack vs. heap delegates.

That is not required for Tango to function properly with D2. It's a 
performance optimization only. A significant one, but no more.
October 12, 2008
Re: backporting features to D1
Christopher Wright schrieb:
> Jarrett Billingsley wrote:
>> Then address the issues of stack vs. heap delegates.
> 
> That is not required for Tango to function properly with D2. It's a
> performance optimization only. A significant one, but no more.

I disagree here.
If you use lambdas for filters in inner loops, that is a main
performance hit. It is more than just "optimization", it is a reason to
change the design. It is a reason not to use D2. It is a D2 show-stopper.
Even worse, no error message is showing you the problematic places, D2
just makes your heap explode.

int findMyTypeXYZ( MyType[] a, int criteria ){
	int match = convCrit( criteria );
	return tango.core.Array.findIf( a, delegate bool(T e){ return e.attrib
is match; });
}

First this run without allocation, now it does allocate.
Image how this behave if called very often :(
And even worse, there is no way to manually delete the allocated stack
frames. So there is no way around the GC runs.
Finally I would end up in rewriting that code, not using a delegate
based design. But IMHO this is one of the important D features.
1 2 3
Top | Discussion index | About this forum | D home