On 9/6/11, Adam Ruppe <destructionator@gmail.com> 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?
>

Isn't it time we start eating our own dogfood and introduce version statements into Phobos to select deprecated functionality? Naming modules "xml.old1", "xml.old2" reminds me of using zip files as a poor man's version control system.

Jacob Carlborg wrote:
> You can always keep your own local copy of a module.

Yeah, though that comes with it's own set of pains.

But, let me ask you this. Which is better?

1) Ask an unknown number of people to change their code to keep up with your changes and/or distribute the old module

or

2) Ask just one person - who is making changes anyway - to make one more small change and distribute the old and new modules.



One counterpoint to this would be "why make people download old modules they don't need in the zip?" There's two answers to that too:

a) That's a trivial cost. The average Phobos module is about 3 or 4 kilobytes once zipped up. When you're grabbing a > 10 MB zip, three kilobytes is nothing to worry about.

b) If it is a big deal, changing to a download on demand system (like the DIP) can avoid this... especially if the old version is still around and easily accessible by name.

Andrej Mitrovic wrote:
> select deprecated functionality

The problem I have is old code isn't going to change itself to select old functions.

New code, on the other hand, can decide to use new functions since someone is actively writing it.

Therefore, it's less painful to opt in to using new code than to select to use old code.

> Naming modules "xml.old1" [...]

I'd do "xml" and "xml2" rather than "xml.old" since the name is already "xml", and in my view, that's immutable now.

This might be a poor man's version control system, but is that
bad? It's not uncommon for software (or books or movies...)
to have major versions (sequel numbers) in the name.

Thanks to D's module namespacing, that name is the only place it'd be too; the code that uses it still looks natural. It's not like they'd have to write parseXML2() all over the place - like is somewhat common in C.



Would people find it weird that versions are in the name? Maybe, but again, that's common in a lot of places. Just make sure the Phobos docs point to the newest version by default in the left nav panel so people don't have to hunt for what's newest.


Would this naming scheme be a hassle in the source control? I don't think so.

1) If it's a rewrite, it's a different file anyway, even if you gave it the same name; it's not like a patch could apply to both versions.

2) If it's a minor fork, you could surely just apply patches to two branches in git, right? (I don't really know how it works, but I can't imagine it'd be harder than any other branch which I hear git makes easy.)

3) If it's backward compatible, no need to change the number.


My only regret is we didn't have the foresight to call it "std.xml1" in the first place.

Andrej Mitrovic:
> I assume people will just pick the first thing they see

That's why the links on the left should always point to the newest version, and there might be notes in the docs pointing people to newer and older versions.

> "std.xml" looks standard so they would pick that over "std.xml2"

Maybe, but if were just consistent with a scheme, I think it'd be easy enough to learn. It's not uncommon to see sequels named "name 2".

On 9/6/11 11:27 AM, Adam Ruppe wrote:
> Andrej Mitrovic:
>> I assume people will just pick the first thing they see
>
> That's why the links on the left should always point to the newest
> version, and there might be notes in the docs pointing people to
> newer and older versions.
>
>> "std.xml" looks standard so they would pick that over "std.xml2"
>
> Maybe, but if were just consistent with a scheme, I think it'd be
> easy enough to learn. It's not uncommon to see sequels named "name 2".

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.


Andrei

"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.

On 9/6/11, Adam Ruppe <destructionator@gmail.com> wrote:
> Andrej Mitrovic wrote:
>> select deprecated functionality
>
> The problem I have is old code isn't going to change itself to select old functions.

I mean hypothetically with a new version this could be a compile switch:

$ dmd main.d xml.d  # use new version
$ dmd main.d xml.d -version=2.053 # use old version

I'm not exactly sure if it could work like that.. but anyway if it's just xml then we don't have to introduce a whole new way of using deprecated code I guess.

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).

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

The new one will stay regex.

> 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.

Agreed.


Andrei

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.
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.

On 9/6/11 12:24 PM, Marco Leise 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.

Guess I'm destroyed.

Andrei