On 2019/05/07 1:06 PM, Luboš Luňák wrote:
If you're going to already handle the problems, why not handle the awfulness by fixing it, instead of patching it up? The class is broken, and it'll be broken even after you tweak one consequence of the base problem. If the base problem gets fixed, the consequence goes away too.
That would ideal, but this class is used __extensively__ by code that already implements various workarounds and has lots of it's own issues. What I'm doing here is making its behaviour in the empty case more reasonable, and adding asserts that will flush out some of the existing dodgy code. Note I say __some__, there are only a certain amount of regressions we are willing to tolerate in the pursuit of better code :-)
The class can't be both, internally it stores just one value, and there are functions such as the Size ctor or operator<< that do take a side (although in line with the general stupidity, different functions take a different side). And while the class gets used extensively, the usage can be fixed mechanically.
I'd be happy to be proven wrong, but I'm not aware of any mechanical fixes. And I would not be surprised to find code that calls both getWidth() and GetWidth() on the same object. _______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice
