I plan to overhaul a number of modules in Phobos2, such as std.algorithm, std.stdio, and std.random. The changes will render existing code using those modules largely uncompilable. I wonder what a good evolution scheme we should adopt. Walter suggested that I move the old modules in etc/, so changing e.g. std.algorithm to etc.algorithm should make legacy code work.

Is this agreeable? Are there better possibilities?


Thanks,

Andrei

Andrei Alexandrescu Wrote:

> I plan to overhaul a number of modules in Phobos2, such as std.algorithm, std.stdio, and std.random. The changes will render existing code using those modules largely uncompilable. I wonder what a good evolution scheme we should adopt. Walter suggested that I move the old modules in etc/, so changing e.g. std.algorithm to etc.algorithm should make legacy code work.
> 
> Is this agreeable? Are there better possibilities?
> 
> 
> Thanks,
> 
> Andrei

D has a deprecated keyword... Could that be used?

Andrei Alexandrescu Wrote:

> Walter suggested that I move the old modules in etc/, so changing e.g. std.algorithm to etc.algorithm should make legacy code work.
> 
may be std.old.*?

On Sun, Oct 19, 2008 at 3:17 PM, ore-sama <spam@here.lot> wrote:
> Andrei Alexandrescu Wrote:
>
>> Walter suggested that I move the
>> old modules in etc/, so changing e.g. std.algorithm to etc.algorithm
>> should make legacy code work.

A nicer way to do it would be to make it all deprecated (but still operational) in one release, then replace it in the next release.

> may be std.old.*?

I like that better than etc.

Maybe even std.deprecate.*
Or
std_deprecated.*
(I think a package name can't be a keyword, right?  If it could then
I'd say std.deprecated.*)

I don't like etc though -- it doesn't imply to me at all that the stuff inside it would be old and deprecated.

--bb

Jason House wrote:
> Andrei Alexandrescu Wrote:
> 
>> I plan to overhaul a number of modules in Phobos2, such as std.algorithm, std.stdio, and std.random. The changes will render existing code using those modules largely uncompilable. I wonder what a good evolution scheme we should adopt. Walter suggested that I move the old modules in etc/, so changing e.g. std.algorithm to etc.algorithm should make legacy code work.
>>
>> Is this agreeable? Are there better possibilities?
>>
>>
>> Thanks,
>>
>> Andrei
> 
> D has a deprecated keyword... Could that be used?
> 

vote++ for deprecated;

On Sun, 19 Oct 2008 18:04:11 +0900, Bill Baxter wrote:

> On Sun, Oct 19, 2008 at 3:17 PM, ore-sama <spam@here.lot> wrote:
>> Andrei Alexandrescu Wrote:
>>
>>> Walter suggested that I move the
>>> old modules in etc/, so changing e.g. std.algorithm to etc.algorithm
>>> should make legacy code work.
"etc" doesn't mean deprecated or old in any way in letters or the unix etc/ folder.

> A nicer way to do it would be to make it all deprecated (but still operational) in one release, then replace it in the next release.

I think that's the way Tango does it (at least for popular packages).

>> may be std.old.*?
Sounds good!

On Sun, 19 Oct 2008 18:04:11 +0900, Bill Baxter wrote:

> On Sun, Oct 19, 2008 at 3:17 PM, ore-sama <spam@here.lot> wrote:
>> Andrei Alexandrescu Wrote:
>>
>>> Walter suggested that I move the
>>> old modules in etc/, so changing e.g. std.algorithm to etc.algorithm
>>> should make legacy code work.
"etc" doesn't mean deprecated or old in any way in letters or the unix etc/ folder.

> A nicer way to do it would be to make it all deprecated (but still operational) in one release, then replace it in the next release.

I think that's the way Tango does it (at least for popular packages).

>> may be std.old.*?
Sounds good!

On Sun, 19 Oct 2008 18:04:11 +0900, Bill Baxter wrote:

> On Sun, Oct 19, 2008 at 3:17 PM, ore-sama <spam@here.lot> wrote:
>> Andrei Alexandrescu Wrote:
>>
>>> Walter suggested that I move the
>>> old modules in etc/, so changing e.g. std.algorithm to etc.algorithm
>>> should make legacy code work.
"etc" doesn't mean deprecated or old in any way in letters or the unix etc/ folder.

> A nicer way to do it would be to make it all deprecated (but still operational) in one release, then replace it in the next release.

I think that's the way Tango does it (at least for popular packages).

>> may be std.old.*?
Sounds good!

On Sun, 19 Oct 2008 18:04:11 +0900, Bill Baxter wrote:

> On Sun, Oct 19, 2008 at 3:17 PM, ore-sama <spam@here.lot> wrote:
>> Andrei Alexandrescu Wrote:
>>
>>> Walter suggested that I move the
>>> old modules in etc/, so changing e.g. std.algorithm to etc.algorithm
>>> should make legacy code work.
"etc" doesn't mean deprecated or old in any way in letters or the unix etc/ folder.

> A nicer way to do it would be to make it all deprecated (but still operational) in one release, then replace it in the next release.

I think that's the way Tango does it (at least for popular packages).

>> may be std.old.*?
Sounds good!

On Sun, 19 Oct 2008 18:04:11 +0900, Bill Baxter wrote:

> On Sun, Oct 19, 2008 at 3:17 PM, ore-sama <spam@here.lot> wrote:
>> Andrei Alexandrescu Wrote:
>>
>>> Walter suggested that I move the
>>> old modules in etc/, so changing e.g. std.algorithm to etc.algorithm
>>> should make legacy code work.
"etc" doesn't mean deprecated or old in any way in letters or the unix etc/ folder.

> A nicer way to do it would be to make it all deprecated (but still operational) in one release, then replace it in the next release.

I think that's the way Tango does it (at least for popular packages).

>> may be std.old.*?
Sounds good!