www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 'exp' vs 'std'? Forked: Vote for std.process

reply Manu <turkeyman gmail.com> writes:
On 13 April 2013 00:04, Jesse Phillips <Jessekphillips+d gmail.com> wrote:

 On Friday, 12 April 2013 at 06:25:10 UTC, Manu wrote:

 I see this pattern where something is designed, discussed, and then voted
 into phobos. At this time the design looks good on paper, but there is
 very
 little practical experience using the library.
 The problem then is, once accepted, people start using it, and at some
 point some issues are found, or ideas for improvement are made based on
 user experience, but the module can no longer be touched due to the
 general
 phobia of making breaking changes...
I think this needs to happen prior to the formal review/voting. I would say it should be a precursor to starting the official review, however this would raise the bar too high for things like Jacob's Serialization library; he has a working library, but it isn't ready for Phobos and it would be silly to require the translation prior to approving it for Phobos. How we choose to add to the exp module would need some consideration.
I would say, everything, bar nothing. The serialisation library is a good example. It's a complicated system, and it has some history already, offering some confidence from the start. Experience might suggest that it's more-or-less acceptable into phobos. It's obviously seen a few projects, but once something is accepted into phobos, I think it's fair to anticipate its usage to increase significantly, and in many different kinds of projects. As an independent library, it might be evaluated by a potential user, and found not to satisfy the requirements for some reason... they move on and continue looking at alternatives, nobody's the wiser. Once it's in phobos, there's a temptation, even an encouragement to use it because it's 'standard'. At this point, it may be found that the project it wasn't suitable for could be worked with some relatively minor changes, which should be made, and the library becomes more useful and robust... phobos doesn't support this pattern at the moment. I maintain the position that it needs at least a year in the real world before you can truly be confident in it. New things shouldn't be barred from post-release tuning on account of "omg it's a breaking change!".
Apr 12 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 12 April 2013 at 14:27:25 UTC, Manu wrote:
 On 13 April 2013 00:04, Jesse Phillips 
 <Jessekphillips+d gmail.com> wrote:

 On Friday, 12 April 2013 at 06:25:10 UTC, Manu wrote:

 I see this pattern where something is designed, discussed, 
 and then voted
 into phobos. At this time the design looks good on paper, but 
 there is
 very
 little practical experience using the library.
 The problem then is, once accepted, people start using it, 
 and at some
 point some issues are found, or ideas for improvement are 
 made based on
 user experience, but the module can no longer be touched due 
 to the
 general
 phobia of making breaking changes...
I think this needs to happen prior to the formal review/voting. I would say it should be a precursor to starting the official review, however this would raise the bar too high for things like Jacob's Serialization library; he has a working library, but it isn't ready for Phobos and it would be silly to require the translation prior to approving it for Phobos. How we choose to add to the exp module would need some consideration.
I would say, everything, bar nothing. The serialisation library is a good example. It's a complicated system, and it has some history already, offering some confidence from the start. Experience might suggest that it's more-or-less acceptable into phobos. It's obviously seen a few projects, but once something is accepted into phobos, I think it's fair to anticipate its usage to increase significantly, and in many different kinds of projects. As an independent library, it might be evaluated by a potential user, and found not to satisfy the requirements for some reason... they move on and continue looking at alternatives, nobody's the wiser. Once it's in phobos, there's a temptation, even an encouragement to use it because it's 'standard'. At this point, it may be found that the project it wasn't suitable for could be worked with some relatively minor changes, which should be made, and the library becomes more useful and robust... phobos doesn't support this pattern at the moment. I maintain the position that it needs at least a year in the real world before you can truly be confident in it. New things shouldn't be barred from post-release tuning on account of "omg it's a breaking change!".
I strongly agree with this. There needs to be a middle step between the wild-west of independent libraries and the strictly controlled world of standard library.
Apr 12 2013
prev sibling next sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
http://forum.dlang.org/thread/jcksnp$ah8$1 digitalmars.com

My idea was to ship exp branch with phobos so all users could look into 
new code. Not all users follow github/newsgroups/etc.
Apr 12 2013
parent reply Manu <turkeyman gmail.com> writes:
On 13 April 2013 00:41, Piotr Szturmaj <bncrbme jadamspam.pl> wrote:

 http://forum.dlang.org/thread/**jcksnp$ah8$1 digitalmars.com<http://forum.dlang.org/thread/jcksnp$ah8$1 digitalmars.com>

 My idea was to ship exp branch with phobos so all users could look into
 new code. Not all users follow github/newsgroups/etc.
Why a branch though? That implies that people are git-savvy (not as common as you think), and that they even have git installed at all... It should be an exp directory next to std, so anyone can use it.
Apr 12 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 12 April 2013 at 15:05:52 UTC, Manu wrote:
 On 13 April 2013 00:41, Piotr Szturmaj <bncrbme jadamspam.pl> 
 wrote:

 http://forum.dlang.org/thread/**jcksnp$ah8$1 digitalmars.com<http://forum.dlang.org/thread/jcksnp$ah8$1 digitalmars.com>

 My idea was to ship exp branch with phobos so all users could 
 look into
 new code. Not all users follow github/newsgroups/etc.
Why a branch though? That implies that people are git-savvy (not as common as you think), and that they even have git installed at all... It should be an exp directory next to std, so anyone can use it.
Agreed. Git should not be required to *use* phobos, only to *contribute* to it.
Apr 12 2013
prev sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 12.04.2013 17:05, Manu pisze:
 On 13 April 2013 00:41, Piotr Szturmaj <bncrbme jadamspam.pl
 <mailto:bncrbme jadamspam.pl>> wrote:

     http://forum.dlang.org/thread/__jcksnp$ah8$1 digitalmars.com
     <http://forum.dlang.org/thread/jcksnp$ah8$1 digitalmars.com>

     My idea was to ship exp branch with phobos so all users could look
     into new code. Not all users follow github/newsgroups/etc.


 Why a branch though? That implies that people are git-savvy (not as
 common as you think), and that they even have git installed at all...
 It should be an exp directory next to std, so anyone can use it.
I'm sorry, I really meant exp directory, as another "branch" of phobos - not related to git (or any VCS) in any way.
Apr 12 2013
parent Manu <turkeyman gmail.com> writes:
On 13 April 2013 01:27, Piotr Szturmaj <bncrbme jadamspam.pl> wrote:

 W dniu 12.04.2013 17:05, Manu pisze:

 On 13 April 2013 00:41, Piotr Szturmaj <bncrbme jadamspam.pl
 <mailto:bncrbme jadamspam.pl>> wrote:

     http://forum.dlang.org/thread/**__jcksnp$ah8$1 digitalmars.com<http://forum.dlang.org/thread/__jcksnp$ah8$1 digitalmars.com>

     <http://forum.dlang.org/**thread/jcksnp$ah8$1 **digitalmars.com<http://forum.dlang.org/thread/jcksnp$ah8$1 digitalmars.com>

     My idea was to ship exp branch with phobos so all users could look
     into new code. Not all users follow github/newsgroups/etc.


 Why a branch though? That implies that people are git-savvy (not as
 common as you think), and that they even have git installed at all...
 It should be an exp directory next to std, so anyone can use it.
I'm sorry, I really meant exp directory, as another "branch" of phobos - not related to git (or any VCS) in any way.
Fair enough, that thread above went off on a tangent saying they should use branches, so I thought that was the idea.
Apr 12 2013
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 12 Apr 2013 10:27:11 -0400, Manu <turkeyman gmail.com> wrote:

 I maintain the position that it needs at least a year in the real world
 before you can truly be confident in it. New things shouldn't be barred
 from post-release tuning on account of "omg it's a breaking change!".
I hate the 'omg it's a breaking change!' mentality as well. This is an UNRELEASED product. I also hate the idea of creating another javax. Here is what I would suggest for new modules (std.log, std.serialization, etc.): pragma(msg, module.stringof ~ " is experimental, subject to API changes"); After 1 year, remove the pragma, and freeze the API. Now, if there were only some way to make pragma(msg...) only print out when imported from non-library code... -Steve
Apr 12 2013
next sibling parent reply Manu <turkeyman gmail.com> writes:
On 13 April 2013 02:07, Steven Schveighoffer <schveiguy yahoo.com> wrote:

 On Fri, 12 Apr 2013 10:27:11 -0400, Manu <turkeyman gmail.com> wrote:

  I maintain the position that it needs at least a year in the real world
 before you can truly be confident in it. New things shouldn't be barred
 from post-release tuning on account of "omg it's a breaking change!".
I hate the 'omg it's a breaking change!' mentality as well. This is an UNRELEASED product. I also hate the idea of creating another javax.
I don't understand this problem? Why is there a problem moving it when it's ready? It's already understood to be experimental, and the user has already accepted the contract that changes can be made (including moving it to std).
Apr 12 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 12 Apr 2013 12:18:30 -0400, Manu <turkeyman gmail.com> wrote:

 On 13 April 2013 02:07, Steven Schveighoffer <schveiguy yahoo.com> wrote:

 On Fri, 12 Apr 2013 10:27:11 -0400, Manu <turkeyman gmail.com> wrote:

  I maintain the position that it needs at least a year in the real world
 before you can truly be confident in it. New things shouldn't be barred
 from post-release tuning on account of "omg it's a breaking change!".
I hate the 'omg it's a breaking change!' mentality as well. This is an UNRELEASED product. I also hate the idea of creating another javax.
I don't understand this problem? Why is there a problem moving it when it's ready? It's already understood to be experimental, and the user has already accepted the contract that changes can be made (including moving it to std).
Intentions don't always equal reality. If enough people make a stink, it could result in exp being the "official" release of some modules. See standard location of Java's xml library. I like the pragma idea because it does not stop compilation, serves as an adequate warning that things are in flux, and turning off the pragma breaks no code whatsoever. It's basically a warning that your code may break. But if the API is stable, it will be fine, and no changes are needed. With the exp version, you either keep exp.module around forever as a public link to the std.module, or you force people's code to break even though no API has changed. -Steve
Apr 12 2013
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 12 April 2013 at 16:31:50 UTC, Steven Schveighoffer 
wrote:
 With the exp version, you either keep exp.module around forever 
 as a public link to the std.module, or you force people's code 
 to break even though no API has changed.

 -Steve
I like the pragma idea better, but I don't see why an exp.module link couldn't just be deprecated then removed. Even if you have to keep it around for ages, it's hardly going to get in the way much.
Apr 12 2013
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 12 Apr 2013 12:40:46 -0400, John Colvin  
<john.loughran.colvin gmail.com> wrote:


 I like the pragma idea better, but I don't see why an exp.module link  
 couldn't just be deprecated then removed. Even if you have to keep it  
 around for ages, it's hardly going to get in the way much.
There's nothing wrong with it, it's just cruft. And in order to remove it, you necessarily must break code. I just like the no-cruft method better, seems pretty much equivalent to me without the code breaking. -Steve
Apr 12 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/12/13, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 pragma(msg, module.stringof ~ " is experimental, subject to API changes");
I like this better: version(UseExperimentalProcess) { } else pragma(msg, module.stringof ~ " is experimental, subject to API changes"); That way I can turn off the warning by passing -version=UseExperimentalProcess on the command-line. That of course means I take full responsibility for using experimental code.
Apr 12 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 12 Apr 2013 12:49:09 -0400, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 On 4/12/13, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 pragma(msg, module.stringof ~ " is experimental, subject to API  
 changes");
I like this better: version(UseExperimentalProcess) { } else pragma(msg, module.stringof ~ " is experimental, subject to API changes"); That way I can turn off the warning by passing -version=UseExperimentalProcess on the command-line. That of course means I take full responsibility for using experimental code.
The issue I have is e.g. if std.process (a locked-API normal module in this instance) uses std.log (an experimental module subject to API breaking changes). I am not using std.log directly, so my code is not subject to breakage if std.log changes. I assume that since std.process and std.log live together, a change to std.log's API will be covered with an appropriate change to std.process. But I still see the warning without version=UseExperimentalLog. People will simply use that flag and it will become trivial. -Steve
Apr 12 2013
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/12/13, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 The issue I have is e.g. if std.process (a locked-API normal module in
 this instance) uses std.log..
It's just that warnings start to become really annoying after a while. I'd rather be warned every time I create a new project and use std.process (I will likely forget to pass -version=Use..), than be warned every single time I compile without the possibility to silence the compiler.
Apr 12 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 12 Apr 2013 13:17:07 -0400, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 On 4/12/13, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 The issue I have is e.g. if std.process (a locked-API normal module in
 this instance) uses std.log..
It's just that warnings start to become really annoying after a while. I'd rather be warned every time I create a new project and use std.process (I will likely forget to pass -version=Use..), than be warned every single time I compile without the possibility to silence the compiler.
Hence my lamenting for a way to stop it :) At this point though, we don't have anything equivalent to #defines. Hm... how about this idea: 1. Add std.exp.module with the API as it will be WITHOUT warnings 2. Add std.module with your suggested version statement, that publicly import std.exp.module 3. Internal phobos modules that use std.module privately will import std.exp.module directly to avoid the printout 4. upon official release, std.exp.module is moved to std.module, and the warning is removed. Modules in phobos that privately used std.exp.module are updated to import the official version. The only issue I see with this is, if we ever get dynamic libraries, a recompile will work, but an update of the dynamic lib will not. I think a little compiler help here would be immensely useful. -Steve
Apr 12 2013
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/12/13, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 Hence my lamenting for a way to stop it :)
So that's what that was because I couldn't understand it (need a coffee refill honestly). :p
 2. Add std.module with your suggested version statement, that publicly
 import std.exp.module
Yeah it might work, I just hope it doesn't run into one of those nasty cyclic/public import bugs. E.g. http://d.puremagic.com/issues/show_bug.cgi?id=9919 But it probably won't be a problem. 9919 is about cyclic imports, as long as phobos doesn't import the module with a public import all should be fine methinks.
Apr 12 2013
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Friday, 12 April 2013 at 17:27:58 UTC, Steven Schveighoffer 
wrote:
 1. Add std.exp.module with the API as it will be WITHOUT 
 warnings
exp.module?
Apr 12 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 12 Apr 2013 15:16:09 -0400, Kagamin <spam here.lot> wrote:

 On Friday, 12 April 2013 at 17:27:58 UTC, Steven Schveighoffer wrote:
 1. Add std.exp.module with the API as it will be WITHOUT warnings
exp.module?
Right. -Steve
Apr 12 2013
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/12/13, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 On Fri, 12 Apr 2013 15:16:09 -0400, Kagamin <spam here.lot> wrote:

 On Friday, 12 April 2013 at 17:27:58 UTC, Steven Schveighoffer wrote:
 1. Add std.exp.module with the API as it will be WITHOUT warnings
exp.module?
Right.
I'd rather we keep it under "std" to avoiding stealing a name that an external library might already use (it's not stealing per se but it might introduce conflicts).
Apr 12 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 12 Apr 2013 16:15:33 -0400, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 On 4/12/13, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 On Fri, 12 Apr 2013 15:16:09 -0400, Kagamin <spam here.lot> wrote:

 On Friday, 12 April 2013 at 17:27:58 UTC, Steven Schveighoffer wrote:
 1. Add std.exp.module with the API as it will be WITHOUT warnings
exp.module?
Right.
I'd rather we keep it under "std" to avoiding stealing a name that an external library might already use (it's not stealing per se but it might introduce conflicts).
I'd like to take this opportunity to say I don't care what the name is :) That wasn't any part of my suggestion. Whatever was decided as the "place to put experimental modules" is what I meant. -Steve
Apr 12 2013
parent reply Timothee Cour <thelastmammoth gmail.com> writes:
A)
what has been described so far doesn't take into account revamped
modules, only new modules. However revamping modules also needs to be
taken into consideration (there was a discussion before on whether we
should have std.process2, which was agreed to be bad).

Here's a suggestion that would work for both new and revamped modules:

put experimental/revamped modules during staging period under (to take
std.process example):

./phobos/std/process.d //current one
./phobos/experimental/std/process.d //new one, still called module std.process

now instead of having to modify D source files to change 'import
exp.process' into 'import std.process' as has been suggested by some,
here we would only need to change compiler flags:

rdmd $DFLAGS -I$phobos_root/experimental main.d  => uses
experimental/std/process.d if import std.process is mentioned

rdmd $DFLAGS main.d  => uses std/process.d if import std.process is mentioned

B)
To handle fine grained selection of the experimental new/revamped
modules, we can refine the preceding scheme with per-module
identifiers:

rdmd $DFLAGS -I$phobos_root/experimental -J$phobos_root

experimental/std/process.d:

module std.process;
version(experimental_std_process_version_latest)
  mixin(import("experimental/std/experimental_std_process_version_3.d"));
//latest revision
else version(...) //maybe some intermediate revision given by a number
else
  mixin(import("std/process.d").removeFirstLineContainingImportDecl);
//default one

C)
Furthermore, instead of version(AllowExperimental){} else pragma(msg,
"RED FLAG"); that was suggested, we can leverage UDA for more
flexibility:
the logic would enable behavior such as controlling whether to print
warnings depending on whether user code or library depends on
experimental feature.





On Fri, Apr 12, 2013 at 1:25 PM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 On Fri, 12 Apr 2013 16:15:33 -0400, Andrej Mitrovic
 <andrej.mitrovich gmail.com> wrote:

 On 4/12/13, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 On Fri, 12 Apr 2013 15:16:09 -0400, Kagamin <spam here.lot> wrote:

 On Friday, 12 April 2013 at 17:27:58 UTC, Steven Schveighoffer wrote:
 1. Add std.exp.module with the API as it will be WITHOUT warnings
exp.module?
Right.
I'd rather we keep it under "std" to avoiding stealing a name that an external library might already use (it's not stealing per se but it might introduce conflicts).
I'd like to take this opportunity to say I don't care what the name is :) That wasn't any part of my suggestion. Whatever was decided as the "place to put experimental modules" is what I meant. -Steve
Apr 13 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 13 Apr 2013 11:19:50 -0400, Timothee Cour  
<thelastmammoth gmail.com> wrote:

 A)
 what has been described so far doesn't take into account revamped
 modules, only new modules. However revamping modules also needs to be
 taken into consideration (there was a discussion before on whether we
 should have std.process2, which was agreed to be bad).

 Here's a suggestion that would work for both new and revamped modules:

 put experimental/revamped modules during staging period under (to take
 std.process example):

 ./phobos/std/process.d //current one
 ./phobos/experimental/std/process.d //new one, still called module  
 std.process

 now instead of having to modify D source files to change 'import
 exp.process' into 'import std.process' as has been suggested by some,
 here we would only need to change compiler flags:

 rdmd $DFLAGS -I$phobos_root/experimental main.d  => uses
 experimental/std/process.d if import std.process is mentioned

 rdmd $DFLAGS main.d  => uses std/process.d if import std.process is  
 mentioned
How does that work if both modules are std.process? Wouldn't there be a link error? -Steve
Apr 15 2013
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/15/13, Steven Schveighoffer <schveiguy yahoo.com> wrote:
 How does that work if both modules are std.process?  Wouldn't there be a
 link error?
Also someone might want to use both modules (e.g. to use some kind of a transition process). That technique would make this impossible.
Apr 15 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
 How does that work if both modules are std.process?  Wouldn't there be a
 link error?
There won't be a 'duplicate symbol definition', instead, dmd will find the first file on the import path that defines a module std.process. Actually, in the above example, I need to use '-I$phobos_root/experimental' _before_ $DFLAGS, as $DFLAGS already defines -I$phobos_root.
Apr 15 2013
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/15/13, Timothee Cour <thelastmammoth gmail.com> wrote:
 How does that work if both modules are std.process?  Wouldn't there be a
 link error?
There won't be a 'duplicate symbol definition', instead, dmd will find the first file on the import path that defines a module std.process.
Phobos comes as a prebuilt static library, which DMD uses. But Phobos can't be built entirely as a static library if there are two modules with the same name.
Apr 15 2013
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 15 Apr 2013 13:03:07 -0400, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:

 On 4/15/13, Timothee Cour <thelastmammoth gmail.com> wrote:
 How does that work if both modules are std.process?  Wouldn't there be  
 a
 link error?
There won't be a 'duplicate symbol definition', instead, dmd will find the first file on the import path that defines a module std.process.
Phobos comes as a prebuilt static library, which DMD uses. But Phobos can't be built entirely as a static library if there are two modules with the same name.
Yes, that was my question, the library will define two std.process. What would happen? -Steve
Apr 15 2013
parent Timothee Cour <thelastmammoth gmail.com> writes:
ok I was talking about user code. To also make it work with phobos, it
would also have to be recompiled (recompiling just phobos is fast
anyways); the simplest would be the following:

A) user defines an environment variable PHOBOS_INC (which defaults to
-I$phobos_root but can be overridden for example by
-I$phobos_root/experimental -I$phobos_root).

B) $phobos_root/posix.mak (+ windows makefiles) is improved to support
reading in $PHOBOS_INC
currently we have:
STD_MODULES = $(addprefix std/, algorithm array process ...)
we should instead use $PHOBOS_INC to follow the same logic as dmd
would, ie use the first module that comes on the import path and avoid
duplication. Actually I suggested somewhere else to rewrite phobos's
makefile by a simpler makefile written in D. That would make this
easy.



On Mon, Apr 15, 2013 at 10:13 AM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:
 On Mon, 15 Apr 2013 13:03:07 -0400, Andrej Mitrovic
 <andrej.mitrovich gmail.com> wrote:

 On 4/15/13, Timothee Cour <thelastmammoth gmail.com> wrote:
 How does that work if both modules are std.process?  Wouldn't there be a
 link error?
There won't be a 'duplicate symbol definition', instead, dmd will find the first file on the import path that defines a module std.process.
Phobos comes as a prebuilt static library, which DMD uses. But Phobos can't be built entirely as a static library if there are two modules with the same name.
Yes, that was my question, the library will define two std.process. What would happen? -Steve
Apr 15 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
 Also someone might want to use both modules (e.g. to use some kind of
 a transition process). That technique would make this impossible.
If you call it another module name (say exp.process), then: A) you would not be able to test how the rest of phobos interacts with the new std.process unless you also temporarily changed the source files in phobos to include exp.process instead of std.process (messy). B) That could also lead to duplicate extern(C) symbols being defined in both modules. C) you would end up with the same situation that led to javax described above by others: significant amounts of code may start importing exp.process to the point where it's too late to change it back to std.process. ---- In what I proposed, the source never needs to change, only compile flags to specify order of imports. But to answer your concern, if you really want to temporarily import 2 versions of process.d to coexist and be co-importable, you can simply mixin-string-import experimental/std/experimental_std_process_version_3.d from a differently named module (say, std.process2), see my point B in proposal, although that shouldn't be the common use case. note: I just forgot to mention in the proposal that the 'module std.process;' declaration should be commented out from the implementation file experimental/std/experimental_std_process_version_3.d (which makes this module swapping possible).
Apr 15 2013
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/15/13, Timothee Cour <thelastmammoth gmail.com> wrote:
 If you call it another module name (say exp.process), then:

 A) you would not be able to test how the rest of phobos interacts with
 the new std.process unless you also temporarily changed the source
 files in phobos to include exp.process instead of std.process (messy).
But you can't test it otherwise. If the two std.process APIs are different and you change the import switches when building your own code, the code in Phobos will stop compiling.
Apr 16 2013
prev sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 13 Apr 2013 00:27:11 +1000
Manu <turkeyman gmail.com> wrote:

 On 13 April 2013 00:04, Jesse Phillips <Jessekphillips+d gmail.com>
 wrote:
 
 On Friday, 12 April 2013 at 06:25:10 UTC, Manu wrote:

 I see this pattern where something is designed, discussed, and
 then voted into phobos. At this time the design looks good on
 paper, but there is very
 little practical experience using the library.
 The problem then is, once accepted, people start using it, and at
 some point some issues are found, or ideas for improvement are
 made based on user experience, but the module can no longer be
 touched due to the general
 phobia of making breaking changes...
While I think you raise a very good point, I agree with the possible solutions Vladimir suggested in the original thread: Either add them straight to 'std' from the start and just mark it with a big red "EXPERIMENTAL" or perhaps more accurately "NEW MODULE - STILL SUBJECT TO CHANGE!", or make it super-easy to test such modules when they're in the review queue (perhaps via DUB?). Actually, I'd like to see *both*. The "exp vs std" suggestion *could* work, but I think it his a somewhat higher potential for unintended problems down the road.
Apr 12 2013