Re: MI varobj artificial fields

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).


Thanks,

Aleksandar Ristovski
QNX Software Systems

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

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

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

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

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'