Re: Patch: implement new dynamic varobj spec

[nickrob at snap dot net dot nz (Nick Roberts)]

 > I think we've been conservative enough about this code that it is
 > probably reasonable to let people rely on it.  It has been through a lot
 > of vetting.
 > 
 > However, I don't mind adding a note to the manual if other maintainers
 > want that.

Some of the the headaches of MI are due to legacy code.  Hence mi0, mi1, mi2,
etc.  I don't know if others are already using these features but it would
seem sensible to me for frontends to _drive_ MI and not for it to be the other
way around.  For example, here are a couple changes that I would like to see:

1) The displayhint field output from -var-create as well/or instead of from
-var-list-children.  That would be useful for determining whether an element
should be expandable or not.  Types map, list -- yes, type string -- no.
With normal variable objects I just use num_children but this isn't sufficient
for dynamic ones. 

2) If is_map is true, rather than:

  var1.0 = key0
  var1.1 = value0
  var1.2 = key1
  var1.0 = vaue1
  ...

I would prefer GDB to output:

  var1.0       = "map_element"
  var1.0.key   = key0
  var1.0.value = value0
  var1.1       = "map_element"
  var1.1.key   = key1
  var1.1.value = value1

That way the values could be displayed as a tree:

 [-]--0
  |   |
  |   |--key0
  |   |
  |   |--value0
  |
 [-]--1
  |   |
  |   |--key1
  |   |
  |   |--value1


-- 
Nick                                           http://www.inet.net.nz/~nickrob