Hi Maurizio,
Notice that amongst the 7 files using "inline" C,
hanimat.prg is the only one actually using STATIC,
and all those functions have distinct global names
anyway, so IMO the whole problem is quite marginal
and academic.
Not so, IMHO.
The Bcc/xHarbour resolves the function references in a local scope:
HB_INIT_SYMBOLS_BEGIN( hb_vm_SymbolInit_HANIMAT )
........
{ "HANIMATION_STOP", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_STOP )}, &ModuleFakeDyn },
{ "HANIMATION_CLOSE", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_CLOSE )}, &ModuleFakeDyn },
{ "HANIMATION_DESTROY", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_DESTROY )}, &ModuleFakeDyn },
........
From a purely practical POV regarding hwgui, the only
thing I don't see here is what makes ANIMATE
class so different from the other classes, that this
problem is present here, but not in other places.
But in the case
of ANIMATE_*() I think it's by itself useful to
have access to the API in a non-OOP way, too.
I don't agree.
The OOP way have sense just in a self contained implementation and
encapsulation of data and methods. What will happens if you write
your own
CLASS_METHOD C function overloading the one declared at class
declaration?
Why to make a OOP oriented GUI lib if you could make just a set of c
wrapper
functions to API?
Why hide them when they're ready and even useful?
But: In any case (for example if you don't want deal
with future compatibility for these functions), you can
name them __ANIMATE_*(), which will clearly show for
most ppl, that these are internal ones, and they better
not use them.
Of course they are still not "forced" to not use them,
but since hwgui is an open source project, if someone
really wants to use them, they can simply remove the
static and still use them as is :)
Also how would someone get to know about these functions
in the first place? 1) Documentation: don't include these
2) sample code which uses internals: don't use them in
test code. 3) Peeking into source/.obj files (they can
do these anyways).
Maybe this is academic, but i've choosed hwGUI and not MiniGUI just
for the
advantages and the features given by an OOP implementation.
The OOP implementation doesn't suffer in any case IMO.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
