[core] deprecate Match.h implementation detail header

[ferdymercury]

it's one of the 'no-gos' for Debian, high risk of collision, also see #8655 (comment)

[pcanal]

Doesn't this mean that Match.h now need to include TRegexp.h ... maybe better to move to RTypes.h

[ferdymercury]

I'd prefer not touching Rtypes.h since there are other headers in ROOT using nicely using Pattern_t = std::string;
so let's rename to avoid collisions...

[pcanal]

using nicely using Pattern_t = std::string;

Thankfully this is in a different name space and private in ROOT/RFile.hxx we have:

namespace ROOT {
namespace Experimental {
...
class RFileKeyIterable final {
   using Pattern_t = std::string;

The gymnastic (essentially breaking the one definition rule) we have to do to hide a valid header file (with a name that is too generic) does not seems to be the right direction here. Alternative options I can think of:

1. Merge Match.h into TRegexp.h
2. Rename Match.h into ROOT/Match.hxx (including migrating the type and function inside a namespace) - but that might be too 'good' of an upgrade for those functions.
3. Rename Match.h into TRegexpMatch.h (and leave being a deprecated Match.h that includes the new header).

I suspect 3. is the better of this options.

[ferdymercury]

i'd prefer 1 over 3, since the idea is also to reduce the number of headers.
Or 4: putting Pattern_t into Rtypes.h as you suggested first and later remove Match.h.

[pcanal]

i'd prefer 1 over 3, since the idea is also to reduce the number of headers.

In the hypothetical future where all headers are such that there is no risk of naming clashes (all headers in ROOT/ or prefixed by ROOT or ....), what is gained by reducing the number of headers per se? I.e. assume header 1 and header 2 are both defining somewhat distinct API, why would having a single header that concatenate them be an improvement?

Or 4: putting Pattern_t into Rtypes.h as you suggested first and later remove Match.h.

However I realized that it defines a couple of functions that are also shared by multiple compilation unit and may (or may not) be used by user.

[ferdymercury]

My proposal was to just define Pattern_t in the Rtypes.h or TRegexp and move the Makepat function declarations to private headers not installed outside.
Reducing the public interface gives more flexibility to ROOT for later modernize these kind of functions.

Since it's just one typedef what's needed publicly, one header for it seems overkill.

But yeah, if you prefer moving to ROOT/Match.h I am fine with that too.

[ferdymercury]

Actually, I just noticed that these two files are also a builtin, forked and slightly modified from 1991: https://ftp.math.utah.edu/pub/mirrors/minnie.tuhs.org/Unix_Usenet/comp.lang.c/1991-February/017374.html
vs https://github.com/root-project/root/blob/852600061bcacd9b255d44f6312c96b6b1e00a2d/base/src/Match.cxx

so a mix of copyright/licenses apply

So this would imply to me that, in my opinion, these should be privatized, moved to builtins folder, and later go into ROOTclib (#23356), only linked privately, and later (if wanted) replaced with something more modern. It was already old in 1991: https://ftp.math.utah.edu/pub/mirrors/minnie.tuhs.org/Unix_Usenet/comp.lang.c/1991-February/018547.html where they mention also https://ftp.math.utah.edu/pub/mirrors/minnie.tuhs.org/Unix_Usenet/mod.sources/1986-January/000280.html

[github-actions]

Test Results

    22 files      22 suites   3d 11h 29m 36s ⏱️
 3 875 tests  3 875 ✅ 0 💤 0 ❌
76 551 runs  76 551 ✅ 0 💤 0 ❌

Results for commit 1162ddb.

♻️ This comment has been updated with latest results.