Re: [RCF 00/11] Visit varobj available children only in MI

[Yao Qi <yao at codesourcery dot com>]

Thanks for the review, Keith.

On 01/08/2014 02:22 AM, Keith Seitz wrote:
> Why was this feature implemented this way? Specifically, if some varobj 
> children are not available from trace data, isn't the decision to filter 
> this information a function of the user interface? Wouldn't it have 
> sufficed to add a flag to the varobj designating the child as not 
> collected in the trace experiment or unavailable?
> 
> I am definitely /not/ suggesting that this be re-implemented or 
> re-designed. I just want to understand why this was implemented this 
> way. Perhaps there is a significant speed advantage for large trace 
> experiments or some other technical/legitimate reason for this 
> implementation?

We don't want frontends learn much new.  If they already support
pretty-print dynamic varobj, they should support available-children-only
varobj.  Frontends have only to pass option "--available-children-only"
to some MI commands, and then frontends can handle the output as
correctly as it handles pretty-printer's output.

> 
> That aside, one other thing I'd like to ask about: the flag 
> "--available-children-only" rather strikes me like a property of the 
> varobj. Not altogether unlike the display format. Is there a reason a 

It (available-children-only) is a property of varobj, we add a new field
available_children_only in struct varobj_dynamic for this purpose (in
patch 07), at least, it is in the code.

> flag was chosen to implement this over, say, a (new) command like 
> "-var-set-show-available-children-only" or requiring/allowing 
> --available-children-only to be specified on the root varobj creation 
> and "saved"/enforced for all subsequent commands on the varobj and its 
> children?

Yeah, we can have a global setting to decide whether to honour
available-children-only or not, and this global setting can be
set by a new MI command.

> 
> The only rationale I can think of is if a UI wanted to query gdb/mi for 
> varobjs with and without this option. Is that a common use case? Is 

I am not sure how common this use case is, but IMO, it is more flexible,
compared with the approach using global setting.

> there perhaps another use case which I have not considered?

> 
> Finally, I didn't see any mention of documentation updates. This change 
> will require both a manual update and a NEWS entry, documenting the new 
> feature.

It was intended and was mentioned in the cover letter of this series.
There should be some changes during the review, which affect the doc
and NEWS.

> 
> I believe Joel has committed the MI "features" series; an update to this 
> might be desirable [perhaps Joel might be able to offer an opinion].

Right, we can add a new feature "mi-available-children-only" in the
reply of -list-features.

-- 
Yao (éå)