> -----Messaggio originale-----
> Da: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Per conto di
> Szakáts Viktor
> Inviato: venerdì 6 giugno 2008 9.40
> A: Harbour Project Main Developer List.
> Oggetto: Re: R: [Harbour] HB_STATIC_FUNC
> 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_NEW", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_NEW )}, &ModuleFakeDyn },
{ "HANIMATION_ACTIVATE", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_ACTIVATE )}, &ModuleFakeDyn },
{ "HANIMATION_INIT", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_INIT )}, &ModuleFakeDyn },
{ "HANIMATION_OPEN", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_OPEN )}, &ModuleFakeDyn },
{ "HANIMATION_PLAY", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_PLAY )}, &ModuleFakeDyn },
{ "HANIMATION_SEEK", {HB_FS_STATIC | HB_FS_LOCAL}, {HB_FUNCNAME(
HANIMATION_SEEK )}, &ModuleFakeDyn },
{ "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 },
........
> The only "upside" is that you can work
> in one file instead of two when developing, but
> with the cost of creating non-portable code. I'm
> not sure if it's worth it.
The target isn't to work in a single class file, but in having API wrapper
functions not callable outside of a class.
> If speed is critical, or the whole functionality
> is in C anyway, you may also consider moving the
> whole class to C level. (errorapi.c is an example
> for such solution in Harbour).
Maybe this could be the better choice. I'll try it.
> 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?
Maybe this is academic, but i've choosed hwGUI and not MiniGUI just for the
advantages and the features given by an OOP implementation.
Anyway, the truth is i can't to have a static C function be called by a
Harbour prg code and this, apart of academic talks, is a lack IMHO.
Best regards.
Maurizio
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
