View mode: basic / threaded / horizontal-split · Log in · Help
December 03, 2012
Re: Deprecated Library Functions / Methods
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.
December 03, 2012
Re: Deprecated Library Functions / Methods
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.
December 03, 2012
Re: Deprecated Library Functions / Methods
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
December 03, 2012
Re: Deprecated Library Functions / Methods
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.
December 03, 2012
Re: Deprecated Library Functions / Methods
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
December 03, 2012
Re: Deprecated Library Functions / Methods
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
December 03, 2012
Re: Deprecated Library Functions / Methods
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.
December 03, 2012
Re: Deprecated Library Functions / Methods
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.
December 03, 2012
Re: Deprecated Library Functions / Methods
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.
December 03, 2012
Re: Deprecated Library Functions / Methods
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.
1 2 3 4 5 6
Top | Discussion index | About this forum | D home