Re: Help with retreiving children?
- From: Derek Simkowiak <dereks kd-dev com>
- To: Leeman Strout <alaric portone com>
- Cc: gtk-list gnome org
- Subject: Re: Help with retreiving children?
- Date: Mon, 21 Aug 2000 13:38:55 -0700 (PDT)
-> 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.)
--Derek
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]