Re: MI: type prefixes for values

Daniel Jacobowitz
2006-03-24T02:40:38Z

On Sat, Mar 18, 2006 at 03:38:42PM +1300, Nick Roberts wrote:
> > I don't think it makes a difference - it could confuse consumers of MI2
> > anyway - that's all I'm worried about.
>
> I think it means its generally less likely to make a difference. In Emacs, I
> just take the value of the field amd insert it in the appropriate window at
> the appropriate place. Thats why the type currently gets duplicated in the
> locals window. Removing the type prefix just removes that duplication, I
> don't have to make any changes to the lisp code in Emacs. Adding a field,
> however, might break my parser if I'm not expecting it.
>
> However, perhaps you're thinking specifically of Eclipse.

No, it was just the only one I had handy to test.

I'm unsympathetic if adding a new field breaks your parser; MI
is deliberately arranged so that consumers can ignore new fields
that they don't understand.

Anyway, I think I'm OK with this change, but I want to track down one
more thing first.

> > > Since there are likely to be many more changes to MI, I suggest that when
> > > we start making changes for mi3 only, the default remains at mi2. This
> > > will allow a period of development for mi3 during which changes can be
> > > made more freely. It could then be made the default level after it has
> > > stabilised.
> >
> > Yes, this is already how we document -i=mi to work. It's the last
> > finalized version of the protocol.
>
> But there have been many changes to mi2, notably adding the fullname field
> in several places, since it became the default level. I'm just suggesting
> that we don't have mi4, mi5, mi6 etc because it gets too complicated.

Adding the fullname field was considered (as I wrote above) as a
backwards-compatible change. I don't intend on allowing
incompatible changes to sneak into MI2 (well, hopefully...).
MI3 will be ready when it's ready :-)

--
Daniel Jacobowitz
CodeSourcery