Hi Victor,

>  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.
> 
Simply because this was first class in alphabetical order and when i started
to make a wiki (hwgui.altervista.org) to give an updated reference guide on
hwGUI i've analyzed his code. Other classes don't are affected just because
after changing to static the class methods of hAnimate some signal of
incompatibility with Watcom/Harbour was raised and i've stopped to implement
static methods waiting for a solution, and stopped the documenting on wiki,
because in doubt if also to reference the functions or avoid this.

> Why hide them when they're ready and even useful?

Only because i think that once create an object, to call directly his
methods is ever the better and natural way of manage it. 

> 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).
>

Yes, of course, i could hide something that could be hidden natively.
If no solution will came i'll do so, or i'll use some #ifdef __XHARBOUR__
taking decision at compile time about the scope of methods.
Not a problem at all. 

> The OOP implementation doesn't suffer in any case IMO.

I agree, but anyway i still believe that would be better to can write some
static C function (when speed is a must, by example) and can call hem from
(x)harbour code without to make the function globally referenced.
My signalation was just for asking to pay attention to this lack of feature
during your renewed and effective effort about harbour.
Thanks for your attention.
Best regards.
Maurizio

_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to