Moving away from tools module

[Michael Stahl]

On 28.04.2017 00:36, Chris Sherlock wrote:
> Hi all,
> 
> As I'm researching my book on the guts of LibreOffice, I notice that
> tools predates the SAL. In fact it's a bit of a hodge-lodge of files,
> many of which look like they should probably migrated into other modules.
> 
> I cleaned up ErrorHandler, but I thought I'd ask about the other headers
> here:
> 
> - b3dtrans.hxx - I'm assuming the b3d bit means basegfx 3D
> transformations. I've
> submitted https://gerrit.libreoffice.org/#/c/37030/ to move it into
> basegfx but unfortunately it's failing o Windows and I don't currently
> have a working system to determine why the linker is erroring out.

i'm curious why this isn't already in basegfx - perhaps it's some sort
of compatibility layer and there are already equivalent functions in
basegfx or somewhere?  pretty sure i've seen some coordinate
transformation class somewhere, and it wasn't this one... obviously it
can't be moved to basegfx as-is since it uses tools Rectangle.

> - bigint.hxx and fract.hxx - seems to be more appropriate to the sal
> module, possibly the RTL? Great to get thoughts of others on this one

BigInt *predates* availability of 64-bit integers - i bet many of its
users would be fine with a sal_Int64 and don't need arbitrary precision.
 it even uses "short"s to represent digits, this is 16-bit code...

Fraction is nowadays basically a pImpl wrapper around some boost class
that pulls in 50k lines of amazing template metaprogramming headers so
can't be included everywhere.

> - color.hxx and colordata.hxx - should that migrate to basegfx also?

that already has a color in include/basegfx/color/ ...

> - gen.hxx - includes Pair (shouldn't that be deprecated to std::pair?),
> Point, Size, Range, Selection and Rectangle
> - poly.hxx - polygons
> - line.hxx - lines
> 
> gen.hxx, lines.hxx and poly.hxx all are drawing primitives, wouldn't
> these be better off in basegfx?

these all already exist in basegfx, the problem is that nobody has time
to convert the existing usages of tools classes to basegfx ones, which
is tricky because some of the tools classes are just amazingly badly
designed (see for example documentation of Rectangle class).

> - config.hxx - where would this go? I was thinking the RTL, but it also
> seems like something the VLC might do...

this looks like a class to handle config files - surely something like
this already exists in sal/rtl, for rtl::Bootstrap reading its stuff...

> - contr.hxx - seems better suited in the svx module....

this defines 4 magic constants - why is this still in use? probably a
remnant of the tools-container -> STL conversion of 1897 or when it was?

> - cpuid.hxx - checks for SSE2 support, surely something for the SAL?
> 
> - time.hxx, date.hxx, datetime.hxx and datetimeutils.hxx - these all
> seem to be better suited to the SAL, and actually should we consider
> moving to chrono?

there is a boost datetime thing too, we were looking at that some years
ago but i forgot why we decided not to use it.  perhaps it pulls in 50k
loc of headers everywhere and makes compile times go through the roof
like boost stuff is wont to do.

> - debug.hxx and diagnose_ex.hxx - seems more suited to the RTL...

these mostly contain deprecated macros whose usage should be replaced
with either assert or macros from sal/log.hxx - but it requires
case-by-case decision as to what to replace each call with - we used to
have an easy-hack for that but it was disabled because inexperienced
developers rarely got it right.

> -extendApplicationEnvironment - seems to be a candidate for the OSL...

sal/osl definitely shouldn't be setting a URE_BOOTSTRAP variable - or
any URE layer code for that matter.

> - fldunit.hxx and fontenum.hxx - both seems to be more appropriate in
> the VCL

it appears so, but likely you'll find these to be used in modules that
don't want to depend on VCL.

> There are quite a few headers, but as you can see most look to be more
> appropriately moved to another module.. This would help streamline our
> module dependencies...

i really don't see the point of this.  the tools module is primarily a
toxic waste dump, and distributing the toxic waste across all the other
modules does not look like an improvement to me.  better to remove the
toxic waste from our git repo and dump it in some landfill where nobody
lives, or at least nobody that we know :)