Navigating the Maze

[notbonzo-com]

Hey Daniel,
I really appreciate you for maintaining an open source project like this from the good of your heart and I understand everyone has their own preferred coding style, but this has to be, no joke the most horrid one you could come up with. The fact that everything is a header included by one translation unit would be fine, if you didn't depend on symbols "falling through" from the includes above, which fucks up any LSP trying to help a poor soul read this mess. I see you are vivid on making a lot of files and classes and templates, and while being modular is good, do we really need a templated inherited object of a toggle-able feature which takes a templated feature context, templated by another context (I am already lost) which itself in some instances even is templated by a feature context state which is then also passed as a template parameter of the core context and the code pulls it from god-knows-where on the other end of the project.

That being said, I genuinely appreciate the effort you’ve put into this project, I understand that maybe you like this and/or it is because of performance reasons, However, I believe that introducing some clear documentation or a contribution guide to explain the interactions and design philosophy could go a long way in helping others understand and work with the codebase. Something to help people get a hang of 640 headers (Holy that's insane).

If you’d be open to it, I’d be happy to collaborate on starting to make a simple contribution guide and some way points around the project to make it more accessible to newcomers (or even just making a simple guide on how to add a simple new feature). This way, your build system can remain the same while allowing others to read it.

[cre0z]

+1, I'd be happy to add some docs too (maybe Doxygen too given the size of the project?).

[danielkrupinski]

1. The goal of the single source file is to use compiler optimizations more than the linker optimizations. If there are missing includes in the headers it is an oversight.
2. FeatureToggle class is using CRTP to allow derived class to specify an action to be performed when the feature is turned on or off.
3. HookContext = HookDependencies class. Context is the context class of the feature in which it is used (FeatureNameContext). So despite HookContext and Context being template parameters you known their types if you understand the concept.

You can check recent commits implementing new features to know what is needed for a complete feature.

[notbonzo-com]

Ok I have fixed up the missing include's preventing LSP's from working properly. As there is no CoC I am unsure if I should make a branch and pr on the branch or just make a pr to merge into master directly?

[notbonzo-com]

Also can you maybe not include a billion random stl headers which you don't use in every other file? Also std::less is in not , I know you messed it up because you don't use anything from algorithm <3

[notbonzo-com]

Do we really need the folders here? I mean do we just love more pain and suffering?

[notbonzo-com]

Anyway, after reading almost the entire codebase (apart from window stuff) I can confidently say that I am not a fan of this and that this "way of writing code" is basically source obfuscation. It could easily be fit in >80 headers and be as modular as it is now.

[notbonzo-com]

Ok based on Of course you can make a pull request I will make a pr into master