On Sep 6, 2011, at 10:16 AM, Andrei Alexandrescu wrote:

> On 9/6/11 12:05 PM, Daniel Murphy wrote:
>> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org>  wrote in message news:j45isu$2t3h$1@digitalmars.com...
>>> 
>>> Yah, I also think the documentation makes it easy to clarify which module is the preferred one.
>>> 
>>> I think there's a lot of merit to simply appending a '2' to the module name. There only place where the '2' occurs is in the name of the module, and there aren't many modules we need to replace like that.
>> 
>> I still can never remember if I'm supposed to be using std.regex or std.regexp.
> 
> Yet another argument :o). I also don't quite remember right now whether strstream or stringstream is the new one (I think the latter).

The latter.  I never forget this one because the name we're supposed to use is annoyingly long :-)

"Adam Ruppe" <destructionator@gmail.com> wrote in message news:j43nl0$2f85$1@digitalmars.com...
> Count me as another who is sick and tired of the gratuitous breaking changes every damned month.
>

I understand this, and it's a pain to have to change code every release, but I don't think phobos is _anywhere near_ ready to stop breaking.  The good news is that the pace of releases has slowed down so it's only every couple of months.

> The worst part is there's still some new stuff I actually want each month, so I'm not doing my usual strategy of never, ever, ever updating software.
>
> It's just pain. Trivial changes are easy enough to fix, but are a pain. More complex changes cost me time and money. (I'm still angry about the removal of std.date. But soft deprecation is even worse - I hate that so much the first thing I do when updating my dmd is to edit the source to get that useless annoying shit out of there)

How difficult is the process of moving std.date to your own code? (or any other phobos module)   How could this be made easier?  I don't think the answer is keeping these (broken) modules in phobos.

On Tue, 06 Sep 2011 13:24:34 -0400, Marco Leise <Marco.Leise@gmx.de> wrote:

> Am 06.09.2011, 17:39 Uhr, schrieb Steven Schveighoffer <schveiguy@yahoo.com>:
>
>> On Tue, 06 Sep 2011 11:11:27 -0400, Andrei Alexandrescu
>>> Honest, C's openmode strings have been around for so long, they hardly confuse anyone anymore. I'd rather use "rw" and call it a day.
>>
>> That's not a valid fopen string ;)
>
> Sorry, but I had to laugh. There could not have been a better counter example for using fopen strings. I can live with them, but it is one of the bad designs in C that could use an alternative.

I agree, but: 1. strings are statically checkable in D (see my openFile for an example), and 2. just because the flags were poorly chosen in C doesn't mean we must adhere to that spec.  In other words, "rw" is not a valid fopen mode string, but it *could* be a valid std.stdio mode string.

> Enums         are used in: Unix, Windows, Delphi, Haskell, Lisp, C++, C#, OCaml, Go
> fopen strings are used in: C, Ruby, PHP, Python, NodeJS
> Java has reinvented mode strings: http://download.oracle.com/javase/1.4.2/docs/api/java/io/RandomAccessFile.html#RandomAccessFile(java.io.File, java.lang.String)
> Other languages also distinguish only between a fixed set of cases, like read, write and append. I found Scala and Perl to do that.
>
> In the end a string just like an enum with the enum being statically checked and the string being shorter. Every character corresponds to an 'ored' enum value. They can both be extended with flags that work with Windows and Posix, like 'create only if non-existent' or hints that may work on one system only, like exclusive access.

I like enums in terms of writing code that processes them, but in terms of calling functions with them, I mean look at a sample fstream constructor in C++:

fstream ifs("filename.txt", ios_base::in | ios_base::out);

vs.

File("filename.txt", "r+"); // or "rw"

There's just no way you can think "rw" is less descriptive or understandable than ios_base::in | ios_base::out.

-Steve

On 06.09.2011 21:05, Daniel Murphy wrote:
> "Andrei Alexandrescu"<SeeWebsiteForEmail@erdani.org>  wrote in message
> news:j45isu$2t3h$1@digitalmars.com...
>>
>> Yah, I also think the documentation makes it easy to clarify which module
>> is the preferred one.
>>
>> I think there's a lot of merit to simply appending a '2' to the module
>> name. There only place where the '2' occurs is in the name of the module,
>> and there aren't many modules we need to replace like that.
>
> I still can never remember if I'm supposed to be using std.regex or
> std.regexp.

Looking at the docs: std.regexp is scheduled for deprecation (in August ? hm... that was a bit harsh).

> When the new one is finished are we going to have 3?

To the best of my knowledge new one is supposed to be std.regex, and since API is essentially the same, chances are most users won't notice the change :)

Speaking of the whole idea, I like '2' appended, it's clear that it's a new and better version, and it keeps the old code from unnecessary strain.

>
> It's definately benificial to avoid breaking code, but I really disagree
> that phobos has reached that point yet.  The breaking changes need to stop,
> but stopping prematurely will leave phobos permanently disfigured.
>
>


-- 
Dmitry Olshansky

Am 06.09.2011, 11:09 Uhr, schrieb Jonathan M Davis <jmdavisProg@gmx.com>:

> Other major languages (such as Java and C#) have large standard libraries and
> have done quite well with them. In fact, I believe that the large size of
> their standard libraries is generally seen as major advantage of those
> languages.

These languages are platforms with a complete abstraction from the underlying OS and libraries. My JDK installation is 170 MB in size. I would prefer thin wrappers over good existing libraries like curl. Possibly even msxml4/libxml2. Their API differs in some points, but they both offer XPath and other goodies, maybe they can be made compatible with a wrapper.

Daniel Murphy wrote:
> How could [moving a module to your own code] be made easier?

Actually, ironically enough, removing it from Phobos would make it easier, since they the file can simply be copied into my own tree without needing to rename it to avoid conflicts.

This wouldn't apply to a hypothetical std.xml2 though, if it was still called std.xml. Then the old code would still need to find all the imports and rename it.

(Renaming modules  will probably get more annoying as we go forward, since function local imports might encourage more repetition of the module name.)

On 9/6/2011 7:51 AM, Andrei Alexandrescu wrote:
> Let's leave the likes of std.xml and std.json in peace, then pick a
> naming convention for the new ones and create whole new modules replacing them.

std.xml2

will do fine.

On 9/6/2011 5:02 AM, Michel Fortin wrote:
> What Apple does is meant to keep binary
> compatibility.

It doesn't work that well. dmd breaks with every new OS update.

The winner with binary compatibility is, far and away, Microsoft.

On Tue, 06 Sep 2011 19:54:28 +0200, Walter Bright <newshound2@digitalmars.com> wrote:

> On 9/6/2011 7:51 AM, Andrei Alexandrescu wrote:
>> Let's leave the likes of std.xml and std.json in peace, then pick a
>> naming convention for the new ones and create whole new modules replacing them.
>
> std.xml2
>
> will do fine.

Speaking of xml2 I clearly like to see an attempt of buffered lookahead reading for a stream/stdio overhaul.
Writing range adapters with even only fixed lookahead on top of the current stream API is painful.

martin

Am 06.09.2011, 16:51 Uhr, schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> So what should we use? xml2? new_xml? FWIW we use the prefix "new_" at Facebook to good effect. Or should we, au contraire, use "old_" for the old module and advise people who want to stick with the old modules to change their imports?
>
>
> Andrei

What about:

           std.xml1
std.xml -> std.xml2

So std.xml is a symbolic link to std.xml2 in the next release or std.xml2 public imports std.xml ?
This is what /bin/python is on my computer.