On 12/3/2012 1:00 PM, Jonathan M Davis wrote:
> So, yes having a development and stable branch will help manage things, but
> even with that separation, we don't want to be breaking people's code due to
> library changes.

I agree with that sentiment, but I find it to be completely at odds with your desire to clean up and remove clutter from Phobos whether or not that breaks user code.

On Monday, 3 December 2012 at 02:04:01 UTC, Jonathan M Davis wrote:
> It's messy and ugly to leave dead code around in a library.

It's messier and uglier to break everyone else's code because a small group of people with phobos access decided to unilaterally change things.

There's an easy solution to this btw, a versioning scheme in module names:

---
module std.xml;
pragma(msg, "std.xml sux. if you don't wanna break code import std.xml.1 instead. if you wanna use the rox version the latest is std.xml.2");
public import std.xml.1; /* legacy support */
/* if this wasn't an already existing module, we would static assert(0) instead of pragma msg. NEVER use a naked import like this since it is guaranteed to break. At least by picking a major version, you have a fighting chance of unmodified code still working out of the box down the line */
---
module std.xml.1;
public import std.xml.1.4;
---
module std.xml.1.4; // random number btw
/* current std.xml */
---
module std.xml.2;
public import std.xml.2.0;
---
module std.xml.2.0;
/* a brand new std.xml */
---

The package as module thing is some DIP magic but we could do without by naming it std.xml_2 and std.xml_2_0 or whatever too.


Anyway the rules are:

1) Less specific numbers simply forward you to the next specific module, just like symlinks do on the ideal unix .so library. All modules from here on out have a version number, but current modules are grandfathered in, albeit perhaps deprecated.

2) The most specific thing includes the actual code

3) once a file has been released, it is immutable. ALL releases with changes bump up the version number accordingly and go to a new file. I'm sure we can do some kind of git tagging script or whatever to make this simple.

4) Users import a particular major version normally, or may import a minor version if they really want to get super specific.


Boom, code never breaks and we have prettiness.

On Monday, December 03, 2012 13:28:05 Walter Bright wrote:
> On 12/3/2012 1:00 PM, Jonathan M Davis wrote:
> > So, yes having a development and stable branch will help manage things,
> > but
> > even with that separation, we don't want to be breaking people's code due
> > to library changes.
> 
> I agree with that sentiment, but I find it to be completely at odds with your desire to clean up and remove clutter from Phobos whether or not that breaks user code.

My goal has been to clean up Phobos so that we have an API which is reasonable to keep as it is with minor changes, if any at all. Doing so requires breaking code, but once it's done, then you have a clean, stable API. Further changes may end up being necessary from time to time, but they'd be rare and would be done in a backwards compatible manner. But as long as the clean up phase is underway, breaking changes would be invevitable.

As such, I've been perfectly willing to break code as long as there's been warning given first so that people could change their code according to the API changes, but we're moving to a phase where that's not what we want to be doing anymore.

Arguably, the cleaning that has happened has taken too long, and there's still some left which probably needs to be cleaned up, but regardless, we need to start focusing on stabilizing what we have. Fortunately though, most of the APIs that needed fixing have been fixed, and for the most part, those that still need to be fixed are in modules which need to be outright replaced anyway, so we can use the std.xml -> std.xml2 scheme to deal with those.

It's never been the case that I've wanted to break Phobos' APIs all the time in order to make minor improments to them. It's just that I've wanted to clean them up further before stabilizing on what they'll ultimately be.

- Jonathan M Davis

On Sunday, 2 December 2012 at 23:32:56 UTC, Walter Bright wrote:
> On 12/3/2012 10:13 AM, Jonathan M Davis wrote:
>> On Monday, December 03, 2012 09:25:08 Walter Bright wrote:
>>> On 12/3/2012 8:41 AM, Jonathan M Davis wrote:
>>>> Regardless, there's some stuff that's already been deprecated which
>>>> probably should be outright removed at some point here (e.g. the
>>>> deprecated functions in std.string which don't follow the correct naming
>>>> conventions),
>>>
>>> I do not see a compelling reason to remove them. Just leave them deprecated.
>>
>> They're clutter, and they've been deprecated for a while, which means that no
>> one has been able to use them without -d for a while. It's also trivial to fix
>> code which uses them, because they're primarily naming changes. It's just not
>> worth keeping that kind of clutter around in the library IMHO. And the
>> documentation has made it clear that they were going to be removed.
>
> This is really the crux of our disagreement. I do not see a problem with leaving "clutter" around if it prevents breaking existing code. It being trivial to fix user code is not good enough - the fact that the user has to go back and fix stable, working, debugged code is the problem that Chris is saying is preventing him from using D seriously.
>
> Remove them from the documentation, ok, but leave them there. It does not hurt to do so. Let them die on their own, we do not need to push them out the airlock.

The thing that you'll never agree. In fact you are both right : user must be able to rely on D to compile their code for an extended period of time, and cruft must be cleaned at some point.

The 2 are really important. This is why both MUST be ensured, using 2 branches.

Thoses 2 goal are not reconcilable, and no discussion will come up with the best solution. This disagreement is a symptom of a bigger issue.

On 2012-12-02 22:28, Walter Bright wrote:

> For this case (and others like it) I strongly suggest putting the revamp
> in something called std.xml2, and keep std.xml, but let std.xml wither
> and die away of its own accord rather than killing it.

Then we'll be stuck with a stupid name like xml2, just because the correct name was already taken by something broken.

-- 
/Jacob Carlborg

12/3/2012 3:32 AM, Walter Bright пишет:
> On 12/3/2012 10:13 AM, Jonathan M Davis wrote:
>> On Monday, December 03, 2012 09:25:08 Walter Bright wrote:
>>> On 12/3/2012 8:41 AM, Jonathan M Davis wrote:
>>>> Regardless, there's some stuff that's already been deprecated which
>>>> probably should be outright removed at some point here (e.g. the
>>>> deprecated functions in std.string which don't follow the correct
>>>> naming
>>>> conventions),
>>>
>>> I do not see a compelling reason to remove them. Just leave them
>>> deprecated.
>>
>> They're clutter, and they've been deprecated for a while, which means
>> that no
>> one has been able to use them without -d for a while. It's also
>> trivial to fix
>> code which uses them, because they're primarily naming changes. It's
>> just not
>> worth keeping that kind of clutter around in the library IMHO. And the
>> documentation has made it clear that they were going to be removed.
>
> This is really the crux of our disagreement. I do not see a problem with
> leaving "clutter" around if it prevents breaking existing code.

Code is not broken it just works only with version xyz. The library is only a part of the picture. The other 3rd party code also does change. So is the compiler.

> It being
> trivial to fix user code is not good enough - the fact that the user has
> to go back and fix stable, working, debugged code is the problem that
> Chris is saying is preventing him from using D seriously.
>

It is strange to crave for the latest version and expecting nothing to change. But it's very human thing to want it.

My experience is that old modules are usually not properly maintained nor critical bugs are fixed. As long as scarce unittests pass its deemed working fine.

If changes were only for the sake of change in API I might agree with you.

For instance I had to patch std.outbuffer for DMDScript on D2 to work (not just compile but *work*). Even back then the patch was rejected. So what to do? Download the old version and maintain it on your own. It's Opensource after all. Same goes for std.signal, std.regexp.

Just keeping them forever in the standard library has it share of problems.
- There is a whole cluster of people who learn by example that is the old code (not the official docs).
- If they are in library then we take the burden for keeping these cadavers going.
- Bottom line is that 10 year from now we would still have to deal with them daily (and the bugs nobody knows how to fix) but without the documentation.

Dead code is unavoidable (and grim) part of open-source. Not a single project lives without the constant work on accommodating updates to its components.

> Remove them from the documentation, ok, but leave them there. It does
> not hurt to do so. Let them die on their own, we do not need to push
> them out the airlock.

Either way it's compiler bug-fixes that amount to the most of code broken. It was wrong code but we had no spec and it seemed to work.

Everything in the library goes through a painful cycle of about a year. During that time the most code that is "just there" in the wild got broken over a trivial fix in the compiler anyway.

The truth of it is that the code wont update itself and it's too damn early to expect it to be backwards compatible forever. You may want it badly but it's not going to happen without a full halt of development on all fronts. And that's something nobody wants.

Like I said deprecation is the part of every evolving library project under the sun. Let's finally accept some evolutionary process (and rules) and follow it.

-- 
Dmitry Olshansky

On 12/3/2012 6:48 PM, Dmitry Olshansky wrote:
> My experience is that old modules are usually not properly maintained
> nor critical bugs are fixed. As long as scarce unittests pass its deemed
> working fine.
>
> If changes were only for the sake of change in API I might agree with you.

Except that is what a lot of them are - simply name changes. Also, I have updated a lot of code to deal with removed Phobos functions and modules. This code was *not* broken in its original form.

On 12/3/2012 6:44 PM, Jacob Carlborg wrote:
> On 2012-12-02 22:28, Walter Bright wrote:
>
>> For this case (and others like it) I strongly suggest putting the revamp
>> in something called std.xml2, and keep std.xml, but let std.xml wither
>> and die away of its own accord rather than killing it.
>
> Then we'll be stuck with a stupid name like xml2, just because the
> correct name was already taken by something broken.

So call it xmlex like Microsoft does. The exact name isn't that precious.

On Monday, 3 December 2012 at 08:37:24 UTC, Walter Bright wrote:
> On 12/3/2012 6:44 PM, Jacob Carlborg wrote:
>> On 2012-12-02 22:28, Walter Bright wrote:
>>
>>> For this case (and others like it) I strongly suggest putting the revamp
>>> in something called std.xml2, and keep std.xml, but let std.xml wither
>>> and die away of its own accord rather than killing it.
>>
>> Then we'll be stuck with a stupid name like xml2, just because the
>> correct name was already taken by something broken.
>
> So call it xmlex like Microsoft does. The exact name isn't that precious.

It is.

Thank you all for taking my input seriously. I do appreciate it. I can understand both "parties", but I think not breaking code is more important than the ideal of a clean library. The reality of coding is (as we all know) that programmers cannot constantly update their code, because there are other more urgent things to be done (bug fixes, new modules etc.). I think it is not fair to accuse a programmer of carelessness simply because s/he didn't have time to check all the deprecation warnings in the library. And from a marketing point of view it's never a good idea to put off users by telling them "Ah don't complain, it's your own fault, you simply weren't careful enough!"

Also, the existence of deprecated methods doesn't encourage me (or others, as far as I know) to keep on using them forever. What usually happens is that when I start to write new code, I use the new methods as soon as they are available (no matter which language I use), and once I am familiar with them, I can step by step replace the old deprecated methods with the new ones. So, the reason I wanted to use the latest version of D was exactly because I wanted to use the new methods. But what happened was that I could not use the new methods, because I had to use an older version of D, yet I didn't want to write new code using deprecated methods. I got stuck properly.

I think ideals have to be adjusted to the reality of coding and not vice versa. I do want to keep on using D as it solved a lot of problems for me and I will update my code once things have calmed down.