Re: RFC: how to handle mutable types in varobj?

[Joel Brobecker <brobecker at adacore dot com>]

Hi Pedro,

Thanks for the feedback. Do you mean that the changes you are talking
about are already in the tree? My interpretation of the current code
was that python pretty-printing was implemented a little ad hoc,
almost as an exception to the normal varobjs... That's why I am
a little confused by the process your went through. That being said,
It's been a few days since I looked at the code, and it took me a long
time to start understanding the code better. I might simply still be
missing many things - I need to study the code again in detail to comment
in detail.

In the meantime:

> Implementing Ada mutable types support through this would mean mutable
> varobjs would be exposed as dynamic=1 varobjs.  I'm not sure that'd be
> a problem?

GDB would set the dynamic property, right? That would work for me.

> With frontends that currently support dynamic varobjs,
> things should simply work.  Non dynamic varobjs were kind of a mistake
> anyway (a !dynamic varobj that is bound to an 10000000 element array
> is wholly fetched in gdb memory at once...).

Agreed!

> That said, if you don't want to go that way, it's fine with me.  Just
> putting it out there..

I would like to do what's right once and for all :-). Of course,
if the "right thing" is costing too much effort, then I might look
for compromises.  But for now, I am still looking for guidance in
terms of the varobj interface itself, and achieve compliance.

For instance, I had imagined the case where some children of a varobj
that has mutated might still be around. But unlike you, I thought I'd
keep it as simple as possible to start, so if it was sufficient to
just reset all the children, well that is an easy thing to do :-).

-- 
Joel