Re: MI: type prefixes for values

[Vladimir Prus <ghost at cs dot msu dot su>]

On Friday 17 February 2006 16:49, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 17 Feb 2006 14:50:16 +0300
> >
> > On Friday 17 February 2006 14:26, Eli Zaretskii wrote:
> > > > From: Vladimir Prus <ghost@cs.msu.su>
> > > > Date: Fri, 17 Feb 2006 13:29:33 +0300
> > > > Cc: gdb@sources.redhat.com
> > > >
> > > > > Are you saying that you don't want to show your users the fact that
> > > > > the pointed object is a function?
> > > >
> > > > At the very least, not in the way that gdb assumes.
> > >
> > > In what way, then?
> >
> > It's only avaiable in tooltip text for a variable. So far, no complaints.
>
> I don't see how is this contrary to what GDB assumes.  GDB passes the
> information to the front end; how the front end displays it, is
> entirely up to the front end.

Because for display in variable tree, frontend prefers not to show any type,
and for display in varible tooltips, it prefers to show the type after the 
value, not before.

> The important thing is, you do use this information.
>
> > In the output of print, the type of variable is sometimes wrapped in
> > {}, sometimes in (), and there are no formal rules a frontend author
> > can use to extract type from this information.
>
> The formal rules can be stated, if that's what is missing.  The code
> that produces the parentheses is deterministic, so the rules for when
> they are used can be defined.

Sure, they can be stated. But:
- I don't think anobody is working on that
- The parsing of that value will have to be done by ad-hoc code, which is 
contrary to MI-goal of being easily parsable.

> > > and why should we force the front end to send
> > > yet another command to get this information?
> >
> > Because it has to do this anyway -- the type is embedded in value only
> > for some special types, and frontend needs type information anyway.
>
> Then perhaps we should add the type info to all arguments, instead of
> removing it from where it exists now.

It might be good idea, but why don't add it as a separate field? I.e. instead
of

  ^done,value="(int *) 0x0"

you'll get

  ^done,value="0x0",type="int *"

In that case, we don't need to document how type is added to value, and 
frontend author don't need to extract the type in ad-hoc way, he's just use 
regular way to access MI field value.

- Volodya