Re: Help with retreiving children?

-> If GTK+ were actually object oriented then all that work would already be
-> done.

	[Entering into the realm of conjecture and tit-for-tat Comp Sci
definitions here...]

	Depending on your definition, GTK+ is objected oriented.  It has
inheritance, classes, a type system, and more OOP characteristics (see
Havoc's book for details).

->  As for "standard object-oriented design"... ummm, I didn't say that
-> was my design objective, I just don't like global variables...  =)

	I should have clarified; I was not suggesting you write a
GtkObject child class, but instead just put your "ConfigPage" module (as
I'm calling it) is in its own .h/.c files.

	The C convention of using a pointer-to-struct as the first
argument of the function (and following the Glib naming scheme to avoid
namespace issues) is what I meant by the "standard object-oriented
design".  Sorry about that, it was really misleading on my part...

-> In my personal view, those set and get functions lead to code bloat that I
-> don't need.  I'll admit to not having actually tested my opinion, but I'm
-> not getting paid to do this and I'm happy with my coding style.

	You could always access the struct components directly without
writing the get/set fxns.  But since that would boil down to a GTK+
function call on a "private" member of your struct, I think the code would
be much clearer if you wrote a get/set.  Plus, when you change that
textentry widget to a combo box, you only need to touch the code in one
place, not every place you grab the value (aka "encapsulation").

	Unless you are calling these functions in a loop that requires
severe optimization, the extra maintainability and clarity of your code
will be well worth the single function call.

-> So is that it?  using global functions instead of global variables?

	If your functions require a pointer to a struct to query/modify,
then I would hesitate to call them "global" since they operate on a
particular instance of a 'class' (read:struct).  But, yes, functions with
a program-wide scope are what *I* would suggest.

	(I write all my personal code in the Glib style, since a GtkObject
is too much hassle and I find the Glib naming conventions particularly
readable.  It doesn't provide data-hiding, but I always write accessors so
that's not a problem for me.)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]