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

[Doug Evans <dje@google.com>]

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.