www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - evolution

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Oct 18 2008
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
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?
Oct 18 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
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;
Oct 19 2008
parent Janderson <ask me.com> writes:
KennyTM~ wrote:
 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;

Perhaps depreciated code could be put under file.deprecated.d (or file.dep.d) and included by the new file, along with the deprecated word, just to keep things tidy. -Joel
Oct 20 2008
prev sibling next sibling parent reply ore-sama <spam here.lot> writes:
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.
 

Oct 18 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
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
Oct 19 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Your post appeared 5 times, please check your posting software.
Oct 19 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
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/ 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.*?


Oct 19 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
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/ 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.*?


Oct 19 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
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/ 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.*?


Oct 19 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
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/ 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.*?


Oct 19 2008
prev sibling next sibling parent Moritz Warning <moritzwarning web.de> writes:
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/ 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.*?


Oct 19 2008
prev sibling parent Moritz Warning <moritzwarning web.de> writes:
On Sun, 19 Oct 2008 13:28:28 -0700, Walter Bright wrote:

 Your post appeared 5 times, please check your posting software.

I noticed. Pan (my news reader) took quite some time to send that message. It worked before. :/
Oct 19 2008
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 I plan to overhaul a number of modules in Phobos2, such as 
 std.algorithm, std.stdio, and std.random.

Regarding std.stdio: the current function writeln() has a large amount of faults. I have fixed about 20 of them in my put()/putr() and str()/repr() functions, but not all them. You can copy part of the code of them from my libs, and I can list some things in this newsgroup. ------------- Regarding std.random: it has to reconcile a wide variety of purposes and needs, often one against each other: 1) It has to allow to write short & quick code; 2) It has to give random numbers very quickly; 3) It has to give high quality random numbers; 4) It has to be used in multi-threaded code. 5) It must be able to perform the most handy and common functions. I think that can be solved adding 3 RND generators and various helper functions. Three different random generators can cover most usage cases: a very fast one, a good one fast enough, and a very good one. - The very fast one is thread-safe, can be based on R250-521. - The default one isn't thread-safe and it's designed for most cases. Not being thread-safe you don't need to create a struct/class to use it, so it allows a short and handy syntax. It can be Kiss used by Tango. - The precise one can be thread-safe, a new version of Mersenne Twister is okay. The helper functions can generate: random integer in closed interval, random integer in interval open on the right, uniform real value in interval, Gaussian real value, random choice among given items, in-place shuffling of sequence, not in-place shuffling, sampling with and without replacement from a given sequence of items. Many more things are possible, but those cover a lot of cases. My d.random module is based on this design, even if few bits aren't finished yet (the R250-521 isn't integrated yet, there's a fault I have recently found in the randInt()). Bye, bearophile
Oct 19 2008
prev sibling parent Don <nospam nospam.com.au> writes:
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?

Since one of the examples given as an aim of the Tango/Phobos merger was to allow std.algorithm to work with Tango IO, it would be a shame to miss the opportunity to improve compatibility.
Oct 19 2008