Re: Discussion: Formalizing the deprecation process in GDB

[Andrew Cagney <cagney at gnu dot org>]

> > > Date: Thu, 07 Oct 2004 11:37:45 -0400
> > > From: Andrew Cagney <cagney@gnu.org>
> > > Cc: gdb@sources.redhat.com
> > >
> > > A system that is being continuously re-factored is not well suited for 
> > > detailed internals documentation - the effort is wasted.
>
>
> Can we say that the features that are not going to change any time
> soon are sufficiently documented?  For example, the CLI is not going
> to be refactored any time soon (AFAIK), and yet its documentation
> includes only 3 functions out of at least 10 it exports.  The
> completion features (I mean their GDB-specific aspects, not the
> general Readline mechanism) are not documented at all.

The way the current CLI code works is i18n busted.  I recently 
deprecated several key CLI functions just to stop people adding code 
using them..  While there are new "draft" interfaces available they are 
just draft, the corresponding internals (and perhaps the interfaces) 
face significant change.

Even the frame code isn't safe, which left the old design in the dust, 
is now its self reaching its limits.  It's looking at a refactoring that 
will fundmentally change both it and the symtab.  From frame has-a 
unwinder; to frame has-a function (is a symbol) has-a unwinder.

etc, etc, etc,

Andrew