On Sat, Feb 23, 2013 at 05:32:08PM -0800, Jonathan M Davis wrote:
> On Saturday, February 23, 2013 20:14:14 Steven Schveighoffer wrote:
> > On Sat, 23 Feb 2013 20:07:43 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
[...]
> > > We might be able to remove std.process eventually and then rename std.process2 to std.process (leaving std.process2.d to import std.process), but Walter (and to some extent Andrei) seems to be very much in favor of leaving stuff around permanently. It's likely that std.process will be deprecated (which now defaults to warning about it rather than giving an error) and eventually undocumented, but actually killing it off may take a bit of doing given Walter's attitude about code breakage. He seems to be perfectly fine with leaving around old, dead code on the off-chance that some older code is using it and would break if it were removed.
> > 
> > I don't see std.date around anymore...
> 
> Yes. I killed it, but Walter has never liked that sort of thing and has been increasingly outspoken about it, and Andrei seems to be jumping on that bandwagon. For instance, IIRC, they both griped about actually removing the deprecated functions from std.string. I'd _very_ much like to get rid of them outright, since they clutter the code and actually were generating errors when used until recently (since they were deprecated before the changes to deprecated). Keeping them around is just plain harmful IMHO, and I may yet manage to kill them off, but they don't seem to like the idea, and I fully expect a similar attitude towards something like std.process. Unfortunately, while replacing old solutions with new, better solutions seems to be fine, it doesn't seem to be okay to actually get rid of the old ones anymore.
[...]

Well, std.regexp got lucky, in that the new module has a subtly different name std.regex, so we can just eventually stop documenting std.regexp but leave it in the codebase for whatever old code that uses it to continue working. Ditto with the upcoming std.io to replace std.stdio.

But I can't think of any better name for the new std.process. :-( I'd suggest std.proc, but I'm pretty sure it will get shot down as it's too short and ambiguous (it could be misinterpreted as std.procedure for example).

Alternatively, I would push for renaming the old std.process to something like old.process (or something else), which is much less of a breakage than deleting it from Phobos outright -- existing code just need to have their imports fixed and will continue working, whereas deleting the module outright leaves existing code with no recourse but to potentially rewrite from scratch. This may be easier to convince Walter & Andrei on, than outright killing old deprecated modules.


T

-- 
There's light at the end of the tunnel. It's the oncoming train.

On Saturday, February 23, 2013 18:39:10 H. S. Teoh wrote:
> Alternatively, I would push for renaming the old std.process to something like old.process (or something else), which is much less of a breakage than deleting it from Phobos outright -- existing code just need to have their imports fixed and will continue working, whereas deleting the module outright leaves existing code with no recourse but to potentially rewrite from scratch. This may be easier to convince Walter & Andrei on, than outright killing old deprecated modules.

Possibly, but Walter takes a very dim view on most any code breakage, even if it means simply changing a makefile to make your code work again, so I'd be very surprised if he thought that moving the current std.process would be acceptable. If Andrei could be convinced, then we could probably do it, but I wouldn't expect him to agree, and IIRC, he had no problem with the std.process2 scheme and might even have suggested it. So, I suspect that your only hope of avoiding std.process2 is if you can come up with a better name.

- Jonathan M Davis

On 2/24/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> I'm not sure this would happen.  In order for a module to be "renumbered",
>
> it needs to be a complete rewrite from scratch, with no common ancestry. If we have anything that goes to 3, something is wrong.  We should not be approving new designs if we plan to get rid of them later.

Ah but how can you guarantee we won't ever need a 3rd rewrite? It's always possible we might need one in the future.

It's also a problem if we have to start remembering version numbers for each module we import. E.g.:

import std.process2;
import std.xml; // oops, did I mean xml2 maybe?
import std.signals2;

It's going to be annoying using Phobos like that. I was going to suggest using version flags, but even that could be annoying, although that feature was practically invented for this kind of problem.

On Sat, Feb 23, 2013 at 06:46:13PM -0800, Jonathan M Davis wrote:
> On Saturday, February 23, 2013 18:39:10 H. S. Teoh wrote:
> > Alternatively, I would push for renaming the old std.process to something like old.process (or something else), which is much less of a breakage than deleting it from Phobos outright -- existing code just need to have their imports fixed and will continue working, whereas deleting the module outright leaves existing code with no recourse but to potentially rewrite from scratch. This may be easier to convince Walter & Andrei on, than outright killing old deprecated modules.
> 
> Possibly, but Walter takes a very dim view on most any code breakage, even if it means simply changing a makefile to make your code work again, so I'd be very surprised if he thought that moving the current std.process would be acceptable. If Andrei could be convinced, then we could probably do it, but I wouldn't expect him to agree, and IIRC, he had no problem with the std.process2 scheme and might even have suggested it. So, I suspect that your only hope of avoiding std.process2 is if you can come up with a better name.
[...]

I suppose std.proc is out of the question? ;-)

I find this rather frustrating... sometimes it feels like Phobos is suffering from premature standardization - we have a module with a design that isn't very good, but just because it somehow got put into Phobos, now it has to stick, no matter what. That's what we should do *after* we have a good design, but at this point, the current std.process clearly isn't ready to be cast in stone yet, yet we insist it can't be changed (at least, not easily). So every little design mistake that got overlooked in review and made it into Phobos becomes stuck, even when the design is really only experimental to begin with.

I think we should seriously consider the idea someone brought up in this forum recently, of an experimental section of Phobos where new stuff is put in, and subject to actual field-testing (as opposed to just toy test cases when it was written), before it goes into Phobos proper. I really do not want to see this problem repeated over and over, and we end up with 15 modules with 2 or 3 appended to their name just because nothing can be changed after it's put in. It really detracts from D's presentability, esp. to outsiders and prospective new users, IMO.


T

-- 
Windows 95 was a joke, and Windows 98 was the punchline.

On Saturday, February 23, 2013 18:58:28 H. S. Teoh wrote:
> I suppose std.proc is out of the question? ;-)

I don't know. Maybe.

> I find this rather frustrating... sometimes it feels like Phobos is suffering from premature standardization - we have a module with a design that isn't very good, but just because it somehow got put into Phobos, now it has to stick, no matter what. That's what we should do *after* we have a good design, but at this point, the current std.process clearly isn't ready to be cast in stone yet, yet we insist it can't be changed (at least, not easily). So every little design mistake that got overlooked in review and made it into Phobos becomes stuck, even when the design is really only experimental to begin with.

To some extent, I agree, but at the same time, we're taking forever to stabilize things, and unless we do, D will never take off, because no one will be able to rely on its API.

> I think we should seriously consider the idea someone brought up in this forum recently, of an experimental section of Phobos where new stuff is put in, and subject to actual field-testing (as opposed to just toy test cases when it was written), before it goes into Phobos proper.

I definitely think that this should be considered. I think that it's often the case that the stuff that makes it into Phobos was either created specifically for Phobos (and didn't get much use ahead of time), or it's someone's personal module that they thought would be useful (in which case, it may have gotten heavy use from them but not by many people besides them). And freezing APIs before they've been field-tested means that we'll be permanently stuck with subpar APIs.

> I really
> do not want to see this problem repeated over and over, and we end up
> with 15 modules with 2 or 3 appended to their name just because nothing
> can be changed after it's put in. It really detracts from D's
> presentability, esp. to outsiders and prospective new users, IMO.

I honestly wouldn't expect many modules to be replaced outright. It's mostly just the older ones which risk that. But if ever have to do that with modules that went through the full review process, then we need to rethink how that's done. A propationary area for modules (where they're in Phobos but not in std yet) may very well help mitigate any such problems.

- Jonathan M Davis

On Sat, 23 Feb 2013 21:30:57 -0500, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> I really do not like the name "std.process2". It is exactly the kind of
> thing that will cause newbies to avoid it and go back to the old badly
> designed std.process, and then come back to complain about it, then when
> told to use std.process2, they will wonder "why the 2?". It's just ugly.

Well, we can make importing std.process uncomfortable (read: print a warning whenever you include it), and it won't be in the docs.

If anything, I would think a newbie would just wonder why the 2.  And then use it :)

I'm not saying I think it's the best situation, but I'm not in charge here...

> OTOH, if we're going to be reorganizing the Phobos module hierarchy,
> then that may be a good time to get the new std.process into the right
> name, and leave the old one somewhere else (maybe remain as
> std.process if the new one goes somewhere else in the hierarchy).

What? AFAIK, this is not in the plan.

If Walter and Andrei are willing to reorganize the whole tree, but have a problem with renaming std.process to std.oldprocess, I feel that's pretty inconsistent...

-Steve

On Sat, 23 Feb 2013 21:46:32 -0500, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 2/24/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
>> I'm not sure this would happen.  In order for a module to be "renumbered",
>>
>> it needs to be a complete rewrite from scratch, with no common ancestry.
>> If we have anything that goes to 3, something is wrong.  We should not be
>> approving new designs if we plan to get rid of them later.
>
> Ah but how can you guarantee we won't ever need a 3rd rewrite? It's
> always possible we might need one in the future.

I can't *guarantee* it, but I think it's counter-productive to keep ripping apart standard library designs and recreating them.  I think after this many years, we should have come up with a design that works well.  That is the point of having it reviewed by all you smart people out there!  If there is wide consensus that std.process2 does not have a good API, or even a large division of opinions, we may need to rethink the API.  I hope this is not the case!

Note, a rewrite of the implementation does not require a rename.  It's the API which is critical to get right the first (or second) time.

> It's also a problem if we have to start remembering version numbers
> for each module we import. E.g.:
>
> import std.process2;
> import std.xml; // oops, did I mean xml2 maybe?

This will print a warning to import std.xml2 instead.

> It's going to be annoying using Phobos like that. I was going to
> suggest using version flags, but even that could be annoying, although
> that feature was practically invented for this kind of problem.

No, version is mutually exclusive.  You can't have all of phobos depending on std.process version 2, but you want to use std.process version 1.  Both would have to be compiled in.  I don't think you can do that with version statements.

My recommendation would be to have an 'old' directory, and if people want to use the old process, use old.process.  We have a nice module system, I think we should use it!

Oh shit, I said I didn't want to get back into this debate again... a lot of good that did...

Forget everything I said...

-Steve

On Saturday, February 23, 2013 22:08:44 Steven Schveighoffer wrote:
> On Sat, 23 Feb 2013 21:30:57 -0500, H. S. Teoh <hsteoh@quickfur.ath.cx>
> > OTOH, if we're going to be reorganizing the Phobos module hierarchy, then that may be a good time to get the new std.process into the right name, and leave the old one somewhere else (maybe remain as std.process if the new one goes somewhere else in the hierarchy).
> 
> What? AFAIK, this is not in the plan.
> 
> If Walter and Andrei are willing to reorganize the whole tree, but have a problem with renaming std.process to std.oldprocess, I feel that's pretty inconsistent...

Any reorganization that occurred would involve leaving the old modules around but have them simply importing the new ones. But there are no definitive plans to rearrange any modules at this point. Some folks complain about how flat Phobos' hierarchy is from time to time, and recently, Don started a discussion on possibly rearranging it, but nothing has been decided.

While it makes some sense to have a deeper hierarchy for newer stuff where appropriate, I'm not at all convinced it's worth the churn of moving any of the old stuff around (even if the equivalent of aliases are left around for the old modules). But we'll see what happens. I expect that nothing will change though, if nothing else, because there hasn't been a big push to change anything, just a few folks complaining about it from time to time.

- Jonathan M Davis

On 2/24/13, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> No, version is mutually exclusive.  You can't have all of phobos depending on std.process version 2, but you want to use std.process version 1.  Both would have to be compiled in.  I don't think you can do that with version statements.

I meant something like this:

std\process1.d  -- old process
std\process2.d  -- new process

std\process.d:
----------
version(OldProcess)
  public import std.process1;
else
  public import std.process2;
----------

Phobos modules which already use std.process would have to be changed to directly import std.process1 or std.process2.

Old user code which wants to still compile using the old process would have to add the -version=OldProcess switch /or/ change import statements to 'import std.process1'.

If the old code wants to use both it can simply import 'std.process1' or 'std.process2' as needed.

New code would simply import std.process and use the new code without having to fiddle with anything.

Jonathan M Davis wrote:
> On Saturday, February 23, 2013 18:39:10 H. S. Teoh wrote:
>> Alternatively, I would push for renaming the old std.process to
>> something like old.process (or something else), which is much less of a
>> breakage than deleting it from Phobos outright -- existing code just
>> need to have their imports fixed and will continue working, whereas
>> deleting the module outright leaves existing code with no recourse but
>> to potentially rewrite from scratch. This may be easier to convince
>> Walter & Andrei on, than outright killing old deprecated modules.
>
> Possibly, but Walter takes a very dim view on most any code breakage, even if
> it means simply changing a makefile to make your code work again, so I'd be
> very surprised if he thought that moving the current std.process would be
> acceptable. If Andrei could be convinced, then we could probably do it, but I
> wouldn't expect him to agree, and IIRC, he had no problem with the
> std.process2 scheme and might even have suggested it. So, I suspect that your
> only hope of avoiding std.process2 is if you can come up with a better name.
>
> - Jonathan M Davis
>

Why not just deprecate everything currently in std.process and drop in the new stuff? It might be a bit ugly, but it prevents both code breakage _and_ a proliferation of "std.module2"s.

My 2 cents,
NMS