Callback node - minar::detail namespace

[0xc0170]

Late for a party in #24, shall we use detail namespace for internal things? (There are already PR in the core-util with detail), lets agree on "internal" namespace name and how to do it in our modules.

@bogdanm @autopulated @bremoran

[bogdanm]

I feel like minar-internal-headers is a bit more suggestive than minar/internal

[autopulated]

"minar/minar-internal-headers" does repeat "minar" redundantly.

The detail namespace & header names are separate issues though. It seems like a good idea to use a detail namespace here, as this header is included implicitly, so someone's IDE might start auto-completing minar::CallbackNode, encouraging its use without someone being aware that it's an internal API.

[bremoran]

I don't care what the internal namespace is, but let's be consistent. I picked namespace detail { for Function because that is what's used within the standard library. I'm open to other suggestions with other reasons. internal for internal APIs makes sense, for example, but whatever we choose, it should be consistent. It also requires an entry in the mbed-os style guide.

I would like to see the header file names changed, where possible, to "hpp" for C++-only headers, to indicate that they only work with C++ code.

[0xc0170]

I'm open to other suggestions with other reasons. internal for internal APIs makes sense, for example, but whatever we choose, it should be consistent. It also requires an entry in the mbed-os style guide.

Same here, I am proposing using a namespace rather than module-internal-file_type folder thing. The namespaces for modules are for example in yotta docs ❓ That's something we can figure out where to place in the separate thread.

Back to the original question: module-internal-headers / +sources vs module/detail/*. I would like us to fix it here, then propagate this to other modules (there are open PR to other modules which have detail used as proposed here).

cc @mjs-arm