On 2011-09-06 17:37, Adam Ruppe wrote:
> Jacob Carlborg wrote:
>> I prefer to use "old_".
>
> There's two big problems with that though:
>
> 1) It still breaks the old code. It's an even easier fix, so this isn't
> too bad, but it is still broken.
>
> 2) What if a third version of a module comes along?

What I don't like is that if there's a function/class/module that should be deprecated but have a good proper name we can't use that name for a new implementation.

Another problem I see is that DMD, D, druntime and Phobos are released in one piece. You should be able to take an arbitrary version of Phobos and use it with the compiler and the language, just as you can with other libraries. Then there could be a better version scheme and you can stay on a given version if you really have to.

1.0.0
Major.minor.build

Increment major when introducing API breaking changes, i.e. removing a method. Increment minor when introducing non-breaking API changes, i.e. adding a new method. Increment build when changing implementation details, i.e. changing an internal data structure from an array to a linked list.

With this version scheme you would know that as long as you stay on 1.x.y your code won't break.

-- 
/Jacob Carlborg

On 2011-09-06 17:11, Andrei Alexandrescu wrote:
> On 9/6/11 10:05 AM, Jacob Carlborg wrote:
>> On 2011-09-06 15:02, Steven Schveighoffer wrote:
>>> Yeah, creating a new file is implied by a combination of modes.
>>>
>>> The one that's confusing I think is that "a" is for append, but "+" kind
>>> of tacks on appending to any other mode. It's not the most well-designed
>>> spec for file opening. Add to that you have the "b" which is a noop on
>>> most OSes.
>>>
>>> There is the possibility that we could accept an alternative open mode
>>> string, which we could design better. But we have to keep fopen's spec,
>>> it's already used everywhere.
>>>
>>> -Steve
>>
>> Ok, I would prefer to use enums if they have sensible names. Something
>> like this:
>>
>> File.open(Mode.read | Mode.write); // for both read and write
>
> 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.
>
> Andrei
>

I disagree.

-- 
/Jacob Carlborg

On 2011-09-06 17:39, Steven Schveighoffer wrote:
> 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 ;)
>
> The plus "+" is odd, especially with "a" meaning "append".
>
> And there's that really useless "b" :)

Exactly.

> But I think this does *not* invalidate the usage of strings to denote
> open mode, it just needs more design. The good thing about it is, we can
> augment the string flags and be binary and perfectly backwards compatible.
>
> -Steve


-- 
/Jacob Carlborg

On 2011-09-06 17:53, Andrej Mitrovic wrote:
> On 9/6/11, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> 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?
>
> I would say that's the right way to go. It's much easier to change an
> import than change code. Perhaps another alternative is to use version
> statements. DFL uses it for deprecated features that are still in the
> codebase and usable.
>
> We don't want to punish people for using newer modules, we should
> encourage it. If they're forced to import "std.xml_new", they'll
> eventually have to change those imports to "std.xml" down the road
> when the older std.xml gets replaced by the new one. I assume people
> will just pick the first thing that they see, "std.xml" looks standard
> so they would pick that over "std.xml2".

Yeah, I hate that with Java interfaces, appending a number. Just because the good proper name is already taken and they can't break existing code.

-- 
/Jacob Carlborg

On 2011-09-06 19: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.
> When the new one is finished are we going to have 3?
>
> 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.

I agree.

-- 
/Jacob Carlborg

On 2011-09-06 19:39, Steven Schveighoffer wrote:
>
> 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

But "r+" is. And that's what I assume will be used when I see a file opening function taking a string "mode" parameter. But if you say that "rw" can/will be used instead than that's better.

-- 
/Jacob Carlborg

On 2011-09-06 19:39, Steven Schveighoffer wrote:
> 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

BTW, I think that using:

Mode.read | Mode.write

Instead of "rw" is the same thing as one should name variables with a proper descriptive names instead of just "a" or "b".

-- 
/Jacob Carlborg

On 2011-09-06 20:00, Walter Bright wrote:
> 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.

Maybe it would work better if you would use the proper API instead of putting __name_beg and __name_end around sections in the binary, i.e. __minfo_beg and __minfo_end.

-- 
/Jacob Carlborg

On 9/7/2011 12:35 AM, Jacob Carlborg wrote:
> On 2011-09-06 20:00, Walter Bright wrote:
>> 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.
>
> Maybe it would work better if you would use the proper API instead of putting
> __name_beg and __name_end around sections in the binary, i.e. __minfo_beg and
> __minfo_end.

Actually, I did follow documented behavior of ld. Unfortunately, ld does not follow the documented behavior.

On 09/07/2011 09:30 AM, Jacob Carlborg wrote:
> On 2011-09-06 19:39, Steven Schveighoffer wrote:
>> 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
>
> BTW, I think that using:
>
> Mode.read | Mode.write
>
> Instead of "rw" is the same thing as one should name variables with a
> proper descriptive names instead of just "a" or "b".
>

I disagree: "rw" is quite obvious because you have context. It is not

Mode.read | Mode.write vs "rw"

but

File("filename.txt", Mode.read | Mode.write);

vs

File("filename.txt", "rw");