MI varobj artificial fields

MI varobj artificial fields

[Vladimir Prus]

Right now, when you're in C++ program and ask for children of a varobj
that has structure type, you don't the the fields. Instead, you get
"public", "private" and "protected" as children.

I don't think this makes very much sense. Presenting access specifies in UI
as items in the tree seems to just clutter things. Especially as in C++, 
classes are either POD, with everything public, or real classes, with everything
private. Protected data is generally frowned upon. So, most often we'll have
a lonely "public" or "private" item having all the real item.

Furthermore, even if class has a mixture of public, protected and private data,
do we expect the user to remember the visibility of the field he's after?

So, I suggest to allow MI to optionally suppress those artificial fields.
Comments?

- Volodya

Re: MI varobj artificial fields

[Pedro Alves]

A Wednesday 16 April 2008 16:20:01, Vladimir Prus wrote:

> So, I suggest to allow MI to optionally suppress those artificial fields.
> Comments?

Should the access be an attribute of the each children, instead of
being children themselves?

-- 
Pedro Alves

Re: MI varobj artificial fields

[André Pönitz]

On Wednesday 16 April 2008 17:20:01 Vladimir Prus wrote:
> Right now, when you're in C++ program and ask for children of a varobj
> that has structure type, you don't the the fields. Instead, you get
> "public", "private" and "protected" as chil dren.
> [...] 
> So, I suggest to allow MI to optionally suppress those artificial fields.
> Comments?

I am very much in favour of having a possibility to suppress these artifical
fields.

Andre'

RE: MI varobj artificial fields

[Marc Khouzam]

> Right now, when you're in C++ program and ask for children of a varobj
> that has structure type, you don't the the fields. Instead, you get
> "public", "private" and "protected" as chil dren.
> [...] 
> So, I suggest to allow MI to optionally suppress those artificial fields.
> Comments?

I also think it is a good idea.
I assume you mean for the private/public children to not be created at all?

That will be also good because children's name are now crowded with those
intermediate levels e.g., f.public.bar.private.x instead of f.bar.x

As you say, this would be optional, so as to keep things backwards compatible,
right?

> Should the access be an attribute of the each children, instead of
> being children themselves?

That seems good too.
But I'm wondering if someone debugging has use of that knowledge?
Isn't the visibility of fields only important up to compile time?


BTW, Andre had brought this up a little while back:
http://sourceware.org/ml/gdb-patches/2008-04/msg00004.html


Marc

Re: MI varobj artificial fields

[Jim Ingham]

What we did at Apple was that we added a setting "set mi-show- 
protections" that "auto-opened" all public/protected/private  
children.  So if you have a class:

class Foo
{
   public:
     int first;
   protected:
     int second;
   private:
     int third;
}

-var-create - * mine
^ 
done 
,name 
= 
"var2 
",numchild 
= 
"3 
",type 
= 
"Foo 
",typecode 
= 
"STRUCT 
",dynamic_type 
= 
"",in_scope 
="true",block_start_addr="0x00001cfc",block_end_addr="0x00001d70"
(gdb)
-var-list-children var2
^done,numchild="3",children=[child={name="var2.public.first",exp="first",numchild="0",type="int",typecode="INT",dynamic_type=""},child={name="var2.private.third",exp="third",numchild="0",type="int",typecode="INT",dynamic_type=""},child={name="var2.protected.second",exp="second",numchild="0",type="int",typecode="INT",dynamic_type=""}]

So if you want you can still show the protections in the UI, but you  
don't have to add a separate step to open them up.  I don't see why  
the presence of "private" etc. really much matters in varobj child  
names that are after all only for machine consumption.  But it is  
annoying to have to go through two steps to see the contents.

Another thing we did was that if the class ONLY had public members  
then we automatically suppress the protections.  That avoids having  
"public" show up for:

struct foo
{
  ...
};

which was kind of dopey.

Jim

On Apr 16, 2008, at 9:26 AM, Marc Khouzam wrote:
>> Right now, when you're in C++ program and ask for children of a  
>> varobj
>> that has structure type, you don't the the fields. Instead, you get
>> "public", "private" and "protected" as chil dren.
>> [...]
>> So, I suggest to allow MI to optionally suppress those artificial  
>> fields.
>> Comments?
>
> I also think it is a good idea.
> I assume you mean for the private/public children to not be created  
> at all?
>
> That will be also good because children's name are now crowded with  
> those
> intermediate levels e.g., f.public.bar.private.x instead of f.bar.x
>
> As you say, this would be optional, so as to keep things backwards  
> compatible,
> right?
>
>> Should the access be an attribute of the each children, instead of
>> being children themselves?
>
> That seems good too.
> But I'm wondering if someone debugging has use of that knowledge?
> Isn't the visibility of fields only important up to compile time?
>
>
> BTW, Andre had brought this up a little while back:
> http://sourceware.org/ml/gdb-patches/2008-04/msg00004.html
>
>
> Marc

Re: MI varobj artificial fields

[Jim Ingham]

On Apr 16, 2008, at 11:06 AM, Aleksandar Ristovski wrote:
> Vladimir Prus wrote:
>> Right now, when you're in C++ program and ask for children of a  
>> varobj
>> that has structure type, you don't the the fields. Instead, you get
>> "public", "private" and "protected" as children.
>>
> Thank you for addressing this!
>
>> I don't think this makes very much sense. Presenting access  
>> specifies in
> UI
>> as items in the tree seems to just clutter things. Especially as in  
>> C++,
>> classes are either POD, with everything public, or real classes, with
> everything
>> private. Protected data is generally frowned upon. So, most often  
>> we'll
> have
>> a lonely "public" or "private" item having all the real item.
>>
>> Furthermore, even if class has a mixture of public, protected and  
>> private
> data,
>> do we expect the user to remember the visibility of the field he's  
>> after?
>
> I don't see a reason to treat them as "children", but I think the
> accessibility info. could be useful as a child's attribute (as someone
> suggested already). If nothing else, for clarity, one (an ide) might  
> choose
> to see/organize fields by accessibility (for whatever reason).

Yeah, I think this was just added so you get the organization for  
free.  Note that if you go switch to an attribute, the UI is going to  
have to reorder the variables to get all the private ones together,  
etc.  The varobj code now does that for you when it puts them into  
children.  But there's no guarantee they'll come that way from the  
debug info, and in fact they sometimes don't.

Note, BTW, I see lots of developers with classes that have public,  
protected & private data, so I'm not sure that whoever is "frowning"  
on various practices is having much success...

Jim

Re: MI varobj artificial fields

[Daniel Jacobowitz]

On Wed, Apr 16, 2008 at 11:21:53AM -0700, Jim Ingham wrote:
> Yeah, I think this was just added so you get the organization for free.  
> Note that if you go switch to an attribute, the UI is going to have to 
> reorder the variables to get all the private ones together, etc.

Is that really what you'd want?  GDB's ptype will group things by
protection in the order they're present anyway, repeating protections
if that's what the source did.  I think this is much more logical.

class foo
{
  public:
    int a;

  private:
    int b;

  public:
    int c;
};

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI varobj artificial fields

[Jim Ingham]

I assumed that in cases where the protections were interleaved it was  
just cruft of history, and if you were going to see protections at  
all, it would make more sense to put them in just three groups.  If  
you have turn-outs, then of course it makes more sense to have three,  
since otherwise you do a little "did I turn out the right private"  
dance which is pretty annoying.  There probably isn't one correct  
answer to this question.

Jim

On Apr 16, 2008, at 11:36 AM, Daniel Jacobowitz wrote:
> On Wed, Apr 16, 2008 at 11:21:53AM -0700, Jim Ingham wrote:
>> Yeah, I think this was just added so you get the organization for  
>> free.
>> Note that if you go switch to an attribute, the UI is going to have  
>> to
>> reorder the variables to get all the private ones together, etc.
>
> Is that really what you'd want?  GDB's ptype will group things by
> protection in the order they're present anyway, repeating protections
> if that's what the source did.  I think this is much more logical.
>
> class foo
> {
>  public:
>    int a;
>
>  private:
>    int b;
>
>  public:
>    int c;
> };
>
> -- 
> Daniel Jacobowitz
> CodeSourcery

Re: MI varobj artificial fields

[Pedro Alves]

A Wednesday 16 April 2008 19:51:03, Jim Ingham wrote:
> I assumed that in cases where the protections were interleaved it was
> just cruft of history, and if you were going to see protections at
> all, it would make more sense to put them in just three groups.  If
> you have turn-outs, then of course it makes more sense to have three,
> since otherwise you do a little "did I turn out the right private"
> dance which is pretty annoying.  There probably isn't one correct
> answer to this question.
>

Depends.  There are good reasons why you'd want to group
your code in some other form than by protection, but that is a
bit off-topic.

What I do believe is important is for the IDE to not mess with
my class' layout when I print some type info (unless
I request it specifically with a "hide-all-private-fields"
kind of switch).  That is an important peace of information
when debugging, that seems to be lost currently with the
access-is-child form?  Of course, removing the nodes removes
this problem -- me, personally, as an IDE user would still
like the fields/members/methods to have some indication
of access/protection visible.  Have no idea if the IDE's are
currently smart enough to gather it from parsing the sources.

-- 
Pedro Alves

Re: MI varobj artificial fields

[André Pönitz]

On Wednesday 16 April 2008 21:16:08 Pedro Alves wrote:
> A Wednesday 16 April 2008 19:51:03, Jim Ingham wrote:
> > I assumed that in cases where the protections were interleaved it was
> > just cruft of history, and if you were going to see protections at
> > all, it would make more sense to put them in just three groups.  If
> > you have turn-outs, then of course it makes more sense to have three,
> > since otherwise you do a little "did I turn out the right private"
> > dance which is pretty annoying.  There probably isn't one correct
> > answer to this question.
> >
> 
> Depends.  There are good reasons why you'd want to group
> your code in some other form than by protection, but that is a
> bit off-topic.

Indeed. As far as I am concerned any such a re-grouping is pretty
much the task of the "frontend". From the "backend" I'd just expect
reasonable data in some kind of order, preferably something
"canonical" like the actual physical layout of the structure.

Any other grouping like grouping accoding to some "protection
data field" can be doen easily in the frontend. I would not expect
that functionality hardcoded into the backend.

> What I do believe is important is for the IDE to not mess with
> my class' layout when I print some type info (unless
> I request it specifically with a "hide-all-private-fields"
> kind of switch). That is an important peace of information 
> when debugging, that seems to be lost currently with the
> access-is-child form?  Of course, removing the nodes removes
> this problem -- me, personally, as an IDE user would still
> like the fields/members/methods to have some indication
> of access/protection visible.  Have no idea if the IDE's are
> currently smart enough to gather it from parsing the sources.

Some are, but it's alway a hassle to combine data coming from
two sources (say, one stream coming from a code parser and
one from gdb output) - especially if neither is 100% reliable...

Andre'