[gtk-list] Macros vs functions

[andrew cogent ca]

Manuel M. T. Chakravarty writes:

 > > That was precisely the point of my post.  IME, it's not a good design
 > > for programs to have to access internal widget members directly.  In OO,
 > > you could say this is defeating the object's encapsulation.  But however 
 > > you choose to describe it, programs that do stuff like this are
 > > dependent on the internal design of the object and that is a "bad
 > > thing" (tm). 
 > > 
 > > I still think an inline function or MACRO provided by GTK would
 > > be the best way to do this.
 > 
 > Actually, even a macro has its disadvantages.  Writing a
 > GTK+ binding for a high-level language (one where C structs
 > cannot be accessed directly, but C functions can be called
 > via a foreign function interface), the lack of query
 > functions is rather annoying.  I myself was wondering
 > whether they are omitted by purpose or just because nobody
 > bothered to implement them.  In case of the latter, I would
 > be willing to supply patches.

As another writer of a GTK+ high-level language binding, I agree
completely.  When I read the GTK+ docs, they stated that part of the
intent was to make it easy to write high-level bindings.  Macros are
the antithesis of language bindings, and have caused me no end of pain
with other graphical toolkits.  My vote is to replace ALL macros with
equivalent functions, or at least supply equivalent functions for all
macros, so that the choice is available to the programmer.  This
implies a macro naming convention that makes it obvious whether the
construct is a macro or a function call.

(As an aside, I would also vote to discourage floating point numbers
as function arguments and returns, but that may not be practical.)

Andrew