Re: [commit] Deprecate remaining STREQ uses

Andrew Cagney
2003-12-04T17:33:00Z

>> Date: Wed, 3 Dec 2003 21:44:04 -0700
>> If a contributor wants to add new code, or fix bugs in existing code,
>>> they should not be increasing the use of existing deprecated mechanisms
>>> (after all we should be able to reasonably expect contributors to not
>>> make matters worse). The prime motivator here should our joint goal to
>>> make GDB the best debgger possible, and more immediatly our desire to
>>> fix bugs such as those identified by my rewritten structs.exp. As for
>>> other code, let it bitrot and die.
>>
>>
>> I agree with much of what you say, but I really can't agree with the
>> last part. There is a quite a lot of code which simply cannot be
>> allowed to "bitrot and die".

Kevin's comment here is way over my head.

Firstly we're actively maintaining and improve our code base, as if we
fail to do this, our code will bitrot and die. This isn't because of
deprecation, rather its because GDB is part of a rapidly chaning world -
GCC changes, the OS changes - and each change creates new and wonderful
requirements while at the same time unearthing old bugs.

An unfortunate consequence of this is that sections of the code base
will fall by the wayside (if they were sufficiently important one of us
would have step up and sort out the mess - as mark has done for the
SPARC). I say let it. We've better things to spend our limited
resources on such as (as eli observed) adding new features and
functionality to GDB.

So, to put it simply, what code?

>> From: Kevin Buettner <kevinb@redhat.com>
>>
>> I have already stated that I think the renaming of deprecated
>> interfaces is okay in some instances. I am concerned, however, that
>> this approach is being used in instances where it doesn't really
>> need to be.
>
>
> Seconded.
>
> Can we conclude this thread by agreeing that renaming of deprecated
> interfaces should be discussed first in cases such as STREQ? I think
> everybody agreed on that at some point.

To speak generally, what happens is:

- an interface is identified as a deprecate candidate
See "deprecate" in the ari for a candidate list - most are macros but
others are cases where the code could do with a refactoring.

- the deprecate candidate gets reviewed, replaced or rewritten
It is at this point that the issue is raised publically, problems in the
old iterface identified and discussed, and the issue resolved. Any old
interfaces get identified as obsolete, ready for the final phase ...

- the now obsolete interface and mechanism get explicitly deprecated
(or removed, depending on how risky it is)

(Of course there are variations on a theme - sometimes the old interface
is deprecated first as that makes the introduction of the new interface
easier.)

So there is already a point at which this deprecate can be discussed.

However, more puzzling is Kevin's generalization that "this approach is
being used in instances where it really doesn't need to be". It
strongly implies that STREQ, rather than being the exception, is the
norm. If if that is the case then more details would be helpful.

Andrew