Deprecated Library Functions / Methods

[Dmitry Olshansky]

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