On Wednesday, 6 February 2013 at 11:33:20 UTC, Jonathan M Davis
wrote:
On Wednesday, February 06, 2013 12:06:18 deadalnix wrote:
Andrei made a proposal to allow transforming a module into a
package. It seems to me like the way to go for this.
Yes, but that's a different issue. It's one thing to take
std.algorithm or
std.datetime and turn them into packages while still allowing
you to import
std.algorithm or std.datetime as before. It's quite another to
completely
replace a module with another module. To do that, you need a
new module.
Anything else will break code. The question then is what to
name the new
module.
If we use the package trick as proposed, a possible solution is :
std/datetime/v1.d :
// Datetime version 1
std/datetime/v2.d :
// Datetime version 2
std/datetime.d or std/datetime/package.d (or whatever) :
version(DATETIME_V1) {
public import std.datetime.v1;
} else {
public import std.datetime.v2;
}
You could replace the entire module in-place, but doing so will
break code,
and Walter in particular is very much against that in general.
Whatever we did
would require allowing people to transition from one to the
other and we might
even have to leave the old one around permanently (which I
don't like, but I'm
sure that Walter would favor). Simply changing it with a new
version of Phobos
wouldn't cut it.
Well Walter seems very worried about breaking code, but seems
unable to adopt any practice the reduce its effect, and in the
facts, my cod break at any new dmd release (and right now compile
with none released one).
