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