Re: [PATCH 4/7] Move struct varobj to varobj.h.

Doug Evans
2013-10-02T19:32:30Z

Joel Brobecker writes:
> > This patch moves most of the fields of struct varobj to varobj.h, and
> > continue to name it 'struct varobj.h' there. New struct
> > varobj_dynamic 'extends' struct varobj in varobj.c.
> >
> > Move part of struct varobj to varobj.h
> >
> > gdb:
> >
> > 2013-09-18 Yao Qi <yao@codesourcery.com>
> >
> > * varobj.c (struct varobj): Move most of the fields to
> > varobj.h.
> > (struct varobj_dynamic): New struct.
> > (varobj_get_display_hint) [HAVE_PYTHON]: Cast 'var' to type
> > 'struct varobj_dynamic'.
> > (varobj_has_more): Likewise.
> > (dynamic_varobj_has_child_method): Change type of parameter
> > 'var' to 'struct varobj_dynamic *'.
> > (update_dynamic_varobj_children): Likewise.
> > (install_visualizer): Likewise.
> > (install_default_visualizer, construct_visualizer): Likewise.
> > (varobj_get_num_children): Likewise.
> > (dynamic_varobj_has_child_method): Adjust.
> > (varobj_list_children, varobj_get_attributes): Likewise.
> > (varobj_set_value, install_new_value): Likewise.
> > (varobj_update, new_variable): Likewise.
> > (my_value_of_variable, value_get_print_value): Likewise.
> > * varobj.h (struct varobj): Moved from varobj.c.
>
> Overall, I like the direction that the whole series is taking.

Me too.

> But this is a patch that makes me a little uncomfortable, because
> I am not sure really want to introduce this kind of polymorphism
> where we cast struct varobj into struct varobj_dynamic.

Me too. :-)

> I would
> need to think about it some more - it seems to me that at the root
> of things, we are always manipulating a varobj_dynamic so it is
> always safe to cast it. But this then begs the question why not
> declare them as struct varobj_dynamic in the first place. The answer
> is probably that we don't want to expose too much of struct varobj,
> and in particular the part dealing with dynamicity and pretty-printers.

We don't have "private" but, heh, Python doesn't either except by convention.
So ... we *could* have a similar convention.
Just a thought for discussion's sake ... :-)
[If C++ is around the corner one might punt, though it couldn't hurt
to document (in some way) what's private and what's not today.]

> Perhaps, and this is thinking out loud, another approach would be
> to make this data part of the public struct varobj, but inside
> an opaque structure?

"works for me"
There's only one constructor (I think), it could handle the details.

> I'd really like feedback from other maintainers who have experience
> in this area...

IWBN to have something that didn't use casting alright.