chore: Reorganize impl/ to better reflect architectural boundaries#211
Merged
Conversation
14b8d20 to
9f30056
Compare
9f30056 to
d2351c5
Compare
fuzzybinary
previously approved these changes
Apr 14, 2026
The SDK doesn't support modularized builds yet _(e.g. there's no support
for building separate DLLs, and no facility for defining what's
public/exported in each module)_, and this PR doesn't attempt to change
that. It simply shuffles around the implementation-layer source code to
be a bit better-organized.
We previously had:
- `src/datadog/impl/`
- `attribute/`
- `core/`
- `feature_types/`
- `core.hpp`
- `context.hpp`
- `...`
- `events/`
- `features/`
- `logging/`
- `rum/`
- `crash_reporting/`
- `json/`
- `platform/`
- `storage/`
- `assert.hpp`
- `diagnostics.hpp`
- `...`
There's not much rhyme or reason to the way things are nested: several
areas of concern that are intrinsic to the core module are kept outside
of `impl/core/`, and the core-vs-features split isn't entirely
self-evident.
As of this PR, we now have:
- `src/datadog/impl/`
- `core/`
- `attribute/`
- `events/`
- `feature_types/`
- `json/`
- `platform/`
- `storage/`
- `util/`
- `assert.hpp`
- `diagnostics.hpp`
- `...`
- `core.hpp`
- `context.hpp`
- `...`
- `logging/`
- `rum/`
- `crash_reporting/`
This structure more directly captures the actual architectural
boundaries, namely:
- There is a single `core` module, then a separate module for each
feature
- Each feature module depends on the `core` module and no others
`CONTRIBUTING.md` (which provides a 10,000-foot overview to orient
contributors to the implementation) is revised to reflect the correct
paths, and to mention a few key details that it was missing before.
61e059a to
e1a6d20
Compare
d2351c5 to
d72900f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The SDK doesn't support modularized builds yet (i.e. there's no support for building separate DLLs, and no facility for defining what's public/exported in each module), and this PR doesn't attempt to change that. It simply shuffles around the implementation-layer source code to be a bit better-organized.
We previously had:
src/datadog/impl/attribute/core/feature_types/core.hppcontext.hpp...events/features/logging/rum/crash_reporting/json/platform/storage/assert.hppdiagnostics.hpp...There's not much rhyme or reason to the way things are nested: several areas of concern that are intrinsic to the core module are kept outside of
impl/core/, and the core-vs-features split isn't entirely self-evident.As of this PR, we now have:
src/datadog/impl/core/attribute/events/feature_types/json/platform/storage/util/assert.hppdiagnostics.hpp...core.hppcontext.hpp...logging/rum/crash_reporting/This structure more directly captures the actual architectural boundaries, namely:
coremodule, then a separate module for each featurecoremodule is self-containedcoremodule and no othersCONTRIBUTING.md(which provides a 10,000-foot overview to orient contributors to the high-level design details of the implementation) is revised to reflect the correct paths, and to mention a few key details that were missing before. Everything else in the diff is purely renames and include-path-fixups.