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

[Melchior F. <mf...@us...>]

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?

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




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

m.