Re: MI varobj artificial fields

["André Pönitz" <apoenitz@trolltech.com>]

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'