Re: [Plib-devel] [BUG] & non-virtual methods (that should be virtual)

[Bram S. <br...@sa...>]

Melchior FRANZ wrote:
> Thanks Bram for committing. And here are two less exciting problems:
> 
> (A) PUCLASS definitions in puAux.h:
> 
>   #define PUCLASS_FILESELECTOR        0x00040000 /* Because FilePicker is obsolete */
>   #define PUCLASS_BISLIDER            0x00080000
>   [...]
>   #define PUCLASS_SPINBOX             0x02000000
>   #define PUCLASS_SCROLLBAR           0x04000000
> 
> Until here this is redundant. It's just copied from pu.h and may
> cause compiler warnings, as pu.h is also included on top of puAux.h.
> I'd remove that or comment it out if it's desirable to keep for
> documentation purposes. But this is less of a cosmetic problem:
> 
>   #define PUCLASS_BISLIDERWITHENDS    0x02000000    // -> 0x08000000
>   #define PUCLASS_SLIDERWITHINPUT     0x04000000    // -> 0x10000000
> 
> Huh? Look above in the redundant part! These two numbers are already
> used! Should be changed to the numbers in the comments, no?

Looks like mistake.
But I guess it goes unnoticed, because nobody seems to use
these special sliders. E.g., they are not used in ./examples,
and google shows little reference too them.


> 
>   #define PUCLASS_COMPASS             0x08000000    // -> 0x20000000
>   #define PUCLASS_CHOOSER             0x10000000    // -> 0x40000000
>   #define PUCLASS_LIST                0x20000000    // -> 0x80000000
> 
> Yes, now we've filled up all bits. But shouldn't classes finally
> be removed after having been tagged "depreciated" for *many* years?
> This would make some room again.  :-)
>

I guess so.

> 
> (B) puaList::getListStringValue() and puaList::getListIntegerValue ()
> 
> These two methods shouldn't have to be there! They are, because
> puObject::getStringValue() and puObject::getIntegerValue() etc. are for
> some reason not made virtual in pu.h. So we couldn't redefine them in
> a derived class and still access them via ((puObject *)foo)->getStringValue().
> But how else would we access the value of a child in a composite widget,
> other than by redefining the getters and returning this child value?
> These extra getters break the interface cleanliness. I suggest to fix
> that in pu.h, and remove this abnormality. (I can send a patch to make
> clearer what I suggest. :-)
> 

Your suggestion sounds right, but the funcs already made their way
into flightgear source, according to google. So maybe make getXxxValue()
virtual, override, and keep the workaround with a warning mesg?

Also:
I want to get rid of those destructors that should have been
virtual,but are not:

psl.h:59: warning: 'class pslNumber' has virtual functions but non-virtual 
destructor
psl.h:133: warning: 'class pslVariable' has virtual functions but non-virtual 
destructor
psl.h:253: warning: 'class pslValue' has virtual functions but non-virtual 
destructor
psl.h:59: warning: 'class pslNumber' has virtual functions but non-virtual 
destructor
psl.h:133: warning: 'class pslVariable' has virtual functions but non-virtual 
destructor
psl.h:253: warning: 'class pslValue' has virtual functions but non-virtual 
destructor
psl.h:59: warning: 'class pslNumber' has virtual functions but non-virtual 
destructor
psl.h:133: warning: 'class pslVariable' has virtual functions but non-virtual 
destructor
psl.h:253: warning: 'class pslValue' has virtual functions but non-virtual 
destructor

I'll fix the virtual thing in cvs,

   Bram


> m.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel