Re: adding support for ptype to MI

[Vladimir Prus <vladimir at codesourcery dot com>]

Dodji Seketeli wrote:

> Keith Seitz wrote:
> 
>> I'm afraid I don't understand what the problem is. Varobj certainly
>> provides a hierarchical view of variables, and that includes type
>> information.
>> 
>> Is that developers want just type information (e.g., for a type
>> browser/inspector kind of thing)? In which case I would expect
>> "-var-create - * (TYPE)0" to work. Alas, I see that is now broken.
> 
> There are times where you don't necessarily want to resort to varobjs.
> 
> For instance, if I can parse the result of "-data-evaluate-expression
> <variable-name>" _quickly enough_, using it incurs less latency than
> using varobjs. At the end of that, that results into a snappier UI for
> the user. And to me, that's a feature.

Do you have concrete numbers?

> Also, as varobjs have to be managed per frame - you have to delete them
> when you leave a frame and that obliges you to send MI commands each
> time you enter a new frame anyway - they obliges the client to do book
> keeping. At least in the current versions of GDB that are shipped on
> most distros.

Did you report those problems?

> So quickly doing -data-evaluate-expression <variable-name> does have its
> need. Similarly, the hypothetical -data-print-type <variable-name> that
> I'd like to see has its need as well.

I'm sorry, I don't see such need yet. My biggest concern is that you start
with using -data-evaluate-expression, which is known to provide output that
ambiguous, hard to parse, and subject to change without notice. Then, you ask
for a command to simplify working with that command. Instead of that, we should
first figure what problems you have with -var-* commands and if those are 
fixeable.

- Volodya