Re: [commit] Deprecate remaining STREQ uses

[Jim Blandy <jimb at redhat dot com>]

[switched to gdb@]

Andrew Cagney <cagney@gnu.org> writes:
> > I suspect that what this boils down to is a difference in maintenance
> > philosophy: I would prefer to see old (deprecated) interfaces eliminated
> > as soon as possible even if it does involve touching possible candidates
> > for deletion, whereas you don't seem to mind having old interfaces
> > retained for longer periods of time.
> 
> To make this more concrete, perhaphs you could outline how this would
> have worked with the old vs new frame code.

Everyone posting so far has agreed that there are cases that are so
complex that deprecation is an appropriate strategy.  Having tried to
incrementally update a port from the old to the new frame interfaces,
but instead having given up and just rewritten it from scratch, I
would say that many aspects of the frame interface are clearly on the
"deprecation is appropriate" side of the line.

The issue at hand, STREQ, and the issue Kevin raised, complaints, are
cases that should have been on the other side of that line: just get
rid of the old uses immediately.  Maybe not in the same commit, but
certainly before taking up other projects.


But I think this principle does apply to the frame interfaces, just on
a different time scale:

After GDB 6.0 was released, you floated some ideas about renovating
the target vector.  While I like the direction these were going, I was
a little distressed to think that we were going to begin the process
of introducing a whole new class of deprecated target-related
interfaces before we had even finished removing uses of the deprecated
frame interfaces.  Certainly, we shouldn't wait for backwater *-tdep.c
files that nobody can test, but we still have deprecated frame
machinery in actively maintained targets like the MIPS and the
PowerPC.

I recognize that you and others have been working on these; I don't
mean to complain or be unappreciative.  But I think we should get
those taken care of before plunging into deprecating interfaces from
an entirely new section of GDB.