Re: [commit] Deprecate remaining STREQ uses

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Nov 24, 2003 at 02:36:47PM -0500, Andrew Cagney wrote:
> 
> >Thank you for the details, Andrew, but you haven't answered Eli's
> >question.  The answer to his question lies in the leap between "blindly
> >transform" and "Consequently" - why not just _leave_ them? 
> >DEPRECATED_STREQ is not an improvement over STREQ except for making
> >things uglier.  We've even got the ARI to remind us; what you've
> >accomplished is shrinking the STREQ/STREQN column to zero at the
> >expense of raising the deprecated column even higher.  If that was all
> >you wanted you could have done it in the ARI scripts.
> 
> David summarized the rationale nicely.  Some additional data points are 
> useful though:
> 
> - no one looks at the ARI
> Looking at the last month of weekly web page summaries they range from:
>    2734	/gdb/
>    ....
>     170	/gdb/current/
>     ...
>      32	/ml/bug-gdb/2000-12/msg00014.html
> but contain not one mention of the ARI (even though I refer to it 
> regularly).

At least one now :)  There are a number of other solutions to this. 
Have you considered making the ARI mail contributors for certain
(low-false-positive) categories?  Like, for instance, this one.  The
gcc-regression mailing list has several scripts to pull the ChangeLog
entries since the last run and mail victims.  It's extremely effective.

> - no one should need to look at the ARI
> GDB's code base should internally document the status of each interface. 
>    That way, when someone goes to hack on something its status is very 
> clear.  Contributors can look at a slab of code and know immediatly that 
> there is a problem.  Maintainers can review a patch and know where a 
> deprecated interface is being used.
> 
> - it's more transparent
> It's clearly far harder for me (and you) to let slip through patches 
> that contain deprecated references.

This is where we disagree, I think.

Not that I'm arguing with either of the above.  But I believe that the
problems (below) need to be considered also.  With work to make the ARI
more used (as opposed to useful) I think you could save everyone a lot
of time.

> >You've been pushing very hard to renaming things to deprecated_foo for
> >a while now.  I think I'm not the only other maintainer who doesn't
> >understand or approve.  It's a lot of work for you; it generates large
> >patches and source churn; it causes patch rejects and merge errors for
> >other developers; and the rest of us don't see or agree on the benefit.
> >Isn't that the sort of thing which should be discussed instead of
> >implemented?
> 
> This isn't exactly new:
> 
> ChangeLog-1998: (struct frame_saved_regs): Deprecate.
> ChangeLog-1998: (EXTRA_FRAME_INFO): Deprecate.
> ChangeLog-1998: (get_frame_saved_regs): Deprecate. Copy the saved regs 
> into the
> ChangeLog-1998: * symfile.c (allocate_symtab): Deprecate use of
> ChangeLog-1999:         memory-write-packet-size''.  Deprecate ``set 
> remotepacketsize''.
> ChangeLog-1999:         print_transfer_performance. Deprecate.
> ChangeLog-1999: deprecated gdb_file_init_astream().
> ChangeLog-1999: * serial.h (DEPRECATED_SERIAL_FD): Define.
> ChangeLog-1999: * serial.c (deprecated_serial_fd): New function.
> ChangeLog-1999: * ui-out.c (struct ui_out): Remove deprecated fields.
> 
> With STREQ discussed:
> 
> ChangeLog-2000: * TODO: Mention ``extern'' and ``STREQ'' cleanups.
> ChangeLog-2000: * defs.h (STREQ, STRCMP, STREQN): Document that these 
> macros are
> http://sources.redhat.com/ml/gdb-patches/2000-q1/msg00667.html
> ('m sure there's a second thread but can't find it).

Sure it isn't new.  Other people grumbling at you when you deprecate
things doesn't appear to be new either.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer