David Roundy-2 wrote:
On Thu, Jun 19, 2008 at 12:57:58PM +0900, Curt Sampson wrote:
On 2008-06-18 15:37 -0700 (Wed), Frederik Eaton wrote:
My only concerns are that deprecating the old interfaces seems like a declaration of intent to eventually remove them.
Just as one opinion, I prefer that old interfaces get removed. I have no problem updating code to deal with this kind of stuff, and the cost of that is easily paid off (for me) in the benefits I get from having simple interfaces available. I found Java's libraries quite trying due to the amount of cruft one was always wading through.
Here's an idea: perhaps deprecated functions should be exported in a new module System.Process.Deprecated? Then they could be left in that module after they've been removed from System.Process, if they ever are removed. That would allow for a slightly easier transition. I don't like the idea of forcing users of System.Process who are happy with the existing interface (e.g. darcs... which is not quite happy with it, but can get by) to either use #ifdefs (or something like that) or to limit their code to specific versions of ghc. Not too long ago, I was bothered by being unable to compile darcs on a system with only ghc 6.2. True, I could have compiled and installed a new ghc, but I didn't want to do so just to get a newer version of darcs, so I'm still using darcs 1.0.2 on that system (which I don't maintain, and is still running debian sarge).
Of course, moving the functions to a new module doesn't help *that* much, but it's easier to change the name of a module imported than to maintain two entirely different codebases for calling external programs (which is rather a fragile part of almost any code that will be using System.Process).
Perhaps a better option would be to keep the old interface indefinitely, but update haddock to allow deprecated interfaces to be documented only on a separate page. Then you needn't break anyone's code, and new users would also not need to wade through a half dozen ancient functions with weird naming conventions.
What's wrong with Simon Marlow's proposed haddock documentation? http://darcs.haskell.org/~simonmar/process/System-Process.html It puts the new stuff at the top. The old stuff goes under "Specific variants of createProcess". The "Synopsis" section doesn't make this separation very clear, and that could be improved, but otherwise it seems good enough. Under 'runProcess' it says "Note: consider using the more general createProcess instead of runProcess.". Sure, Haddock could be updated to put certain interfaces on a separate page or under a collapsed tab. Certainly it would be better to do that than to remove the interfaces (or even put them under a different module name, which still leads to compatibility headaches), but who knows when somebody will have time to make such changes to Haddock. If people want to have a System.Process package with only createProcess and no runProcess, then I still think that the best way to do that would be to make a new package with a new name. That seems preferable to removing names from an existing package, because it doesn't require people to change their code. Frederik -- View this message in context: http://www.nabble.com/Proposal%3A-overhaul-System.Process-tp16844161p1802026... Sent from the Haskell - Libraries mailing list archive at Nabble.com.