leerho commented on issue #502: URL: https://github.com/apache/datasketches-cpp/issues/502#issuecomment-5642092810
## Modernization of `datasketches-cpp` (P.S. I am using Claude and Gemini to help me in my research. Forgive me if any of this comes across as totally crazy!) The 'modernization' effort of C++ involves at least: _(Please add more efforts to this list :) )_ * Move to C++ 14: This allows us to use `[[deprecated]]`, relaxed `constexpr`, and `std::make_unique<...>()`, and more. * A move to C++ 17 would allow one-line nested namespace definitions, `std::optional`, and more. * Refactor / modernize the file structure as discussed in this issue and here. * Adopt a clang-format / Google or LLVM style with a perhaps a few adjustments. From what I read, the Google style is more widely adopted and much better documented. * Refactor and expand the cross-language testing capabilities. * Move the GitHub default branch to `main`. I'm pretty sure the current code compiles fine on C++14 (and maybe 17). With a few exceptions the sketches are pretty independent of each other. This should allow easier compartmentalizing the transition process. ## More thinking about code and filesystem structuring: (Thank you Daniel, for your suggestions!) The problem with the flat namespace (Option B): as a project scales to hundreds of files, a massive single namespace introduces three practical problems for humans and tooling: **Autocompletion Overload:** When a user types `datasketches:: ` in any modern IDE, the _IntelliSense_ drop-down will populate with hundreds or thousands of symbols. This forces the user to scroll through or heavily filter a massive list just to find the specific member they want. **Internal Name Collisions**: While the primary user-facing classes (e.g., theta_sketch, hll_sketch) are protected by their prefixes, the internal helper structures usually aren't. If the `hll_sketch` has an _iterator_ and the `theta_sketch` also needs an `iterator`, they will collide in the flat datasketches namespace unless you rigorously apply prefixes to every single helper file and class as well. **Encapsulation Leakage**: In a flat namespace, all the helper functions for HLL are visible to the developers working on Theta, and vice versa. There is an intermediate approach (Option C) of having just the public facing files in the same top-level, flat directory and namespace, but all internal and test files would live in sub directories and sub namespaces. Test files would have to follow the structure and namespace of the files being tested. Although workable, this might be complicated to remember and navigate. ## My recommendation: (Option A) The advantage of the fully nested approach (Option A) is that it solves file organization, symbol collisions, autocompletion overload, and encapsulation all at once, without requiring manual prefixing. The namespaces would follow the file structure: ### Structure * datasketches/theta/sketch.hpp * datasketches/theta/internal/helper.hpp<br><br> * datasketches/theta/sketch_test.hpp * datasketches/theta/internal/helper_test.hpp<br><br> * datasketches/hll/sketch.hpp * datasketches/hll/internal/helper.hpp<br><br> * datasketches/hll/sketch_test.hpp * datasketches/hll/internal/helper_test.hpp ### Namespaces * datasketches::theta * datasketches::theta::internal<br><br> * datasketches::hll * datasketches::hll::internal ## Commitment I am willing to devote some time to this, but I could use some help from the community with feedback, reviewing PRs, and working in parallel. This is a big job and I'd love to have someone to help me with the migration strategy, at least. We could form a "DataSketches C++ Migration" channel on Slack for more in depth discussion. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
