Re: MI -break-info command issues

[Daniel Jacobowitz <drow@false.org>]

On Fri, Jan 27, 2006 at 06:47:47PM +0300, Vladimir Prus wrote:
> > On Fri, Jan 27, 2006 at 05:59:56PM +0300, Vladimir Prus wrote:
> >> If "minimal" protocol is explicitly not a goal of MI, or changing MI is
> >> prohibited, just say so and I'll stop asking why there are unnecessary
> >> fields.
> > 
> > _Extending_ MI is fine; it was designed to be extensible.  _Removing_
> > fields from MI is not fine, because you don't know if some other
> > frontend relies on the data that you find superfluous.
> > 
> > Folks have said this at least twice in this thread already.  If you
> > disagree, could you say why?
> 
> Because with those fields, you get new issues:
> 
> 1. They are not documented in sufficient detail.
> 2. Looking at 'mi-read-memory.exp', those fields don't appear to be tested
> -- it's only checked that the values of the fields are in hex.
> 3. Everybody using MI should decide if those fields are useful for him, or
> not.

I don't buy it.  If you don't know for sure what they do, and you don't
need them, just ignore them - MI is designed to make unknown fields
easy to ignore.

> The problem with existing frontends can probably be solved by posting a
> prominent message to mailing list whenever MI output is going to change. Or
> using versioning.

This has been discussed before plenty of times.  We will make
incompatible changes to MI from time to time; but IMO that doesn't
justify making _unnecessary_ incompatible changes.

Like Bob, I wouldn't have added the fields.  But since they are
present, I see no reason to remove them.

-- 
Daniel Jacobowitz
CodeSourcery