Date: prev next · Thread: first prev next last
2019 Archives by date, by thread · List index


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.


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.