Skip to content

Stop deriving Namespace from Slice - #512

Open
alexanderlinne wants to merge 1 commit into
mainfrom
stop-deriving-namespace-from-slice
Open

alexanderlinne wants to merge 1 commit into
mainfrom
stop-deriving-namespace-from-slice

Conversation

@alexanderlinne

@alexanderlinne alexanderlinne commented Oct 23, 2026 •

Copy link
Copy Markdown
Collaborator

Namespace has derived from Slice since the initial import, but uses almost nothing from it: the loader creates it with an empty list and fills Types by casting it back, and ArchBuilder only reads Types. The inheritance also gave it Identifier, NameSpace, CountOfAsteriskInPattern and ContainsNamespace(), which mean nothing for a namespace, and tied its Name and FullName to how slices describe themselves.

Namespace is now a class of its own that implements IHasName, IHasDescription and IHasDependencies. Name, FullName, Description, Types, Classes, Interfaces, Dependencies, BackwardsDependencies and equality by full name are unchanged. The loader adds types through an internal AddType instead of the cast.

The namespace parts of PlantUmlFileBuilder.WithDependenciesFrom(slices) move into a new overload WithDependenciesFrom(IEnumerable), so WithDependenciesFrom(Architecture.Namespaces) keeps compiling and drawing the same diagram. The fluent API gets the matching PlantUmlFluentComponentDiagramInitializer.WithDependenciesFromNamespaces, as WithDependenciesFromSlices no longer accepts namespaces. The slice overload and focus mode lose their "slice is Namespace" branches; the comment there already said that namespaces and slices can't be mixed in one diagram.

Both overloads choose dependency targets and drop nodes without dependencies through the same generic helpers. The node removal now collects the nodes before removing them, as removing entries while enumerating a dictionary throws on .NET Framework.

A snapshot of a namespace diagram, recorded before the change, pins the output, and a test pins namespace equality.

Breaking changes:

  • Namespace no longer derives from Slice. Code that used a Namespace as a Slice, or used Identifier, NameSpace, CountOfAsteriskInPattern or ContainsNamespace() on it, no longer compiles.
  • Namespaces can no longer be passed to the slice overload of WithDependenciesFrom or to WithDependenciesFromFocusOn, nor to WithDependenciesFromSlices in the fluent API. Use the namespace overload of WithDependenciesFrom or WithDependenciesFromNamespaces.

@codecov-commenter

codecov-commenter commented Oct 23, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 88.57143% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.54%. Comparing base (f439e0d) to head (72203f8).

Files with missing lines Patch % Lines
ArchUnitNET/Domain/Namespace.cs 66.66% 7 Missing and 4 partials ⚠️
...tNET/Domain/PlantUml/Export/PlantUmlFileBuilder.cs 94.89% 4 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #512      +/-   ##
==========================================
- Coverage   86.55%   86.54%   -0.01%     
==========================================
  Files         261      261              
  Lines       12648    12721      +73     
  Branches     1236     1241       +5     
==========================================
+ Hits        10947    11010      +63     
- Misses       1359     1366       +7     
- Partials      342      345       +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Namespace has derived from Slice since the initial import, but uses
almost nothing from it: the loader creates it with an empty list and
fills Types by casting it back, and ArchBuilder only reads Types. The
inheritance also gave it Identifier, NameSpace, CountOfAsteriskInPattern
and ContainsNamespace(), which mean nothing for a namespace, and tied
its Name and FullName to how slices describe themselves.

Namespace is now a class of its own that implements IHasName,
IHasDescription and IHasDependencies. Name, FullName, Description,
Types, Classes, Interfaces, Dependencies, BackwardsDependencies and
equality by full name are unchanged. The loader adds types through an
internal AddType instead of the cast.

The namespace parts of PlantUmlFileBuilder.WithDependenciesFrom(slices)
move into a new overload WithDependenciesFrom(IEnumerable<Namespace>),
so WithDependenciesFrom(Architecture.Namespaces) keeps compiling and
drawing the same diagram. The fluent API gets the matching
PlantUmlFluentComponentDiagramInitializer.WithDependenciesFromNamespaces,
as WithDependenciesFromSlices no longer accepts namespaces. The slice
overload and focus mode lose their "slice is Namespace" branches; the
comment there already said that namespaces and slices can't be mixed in one diagram.

Both overloads choose dependency targets and drop nodes without
dependencies through the same generic helpers. The node removal now
collects the nodes before removing them, as removing entries while
enumerating a dictionary throws on .NET Framework.

A snapshot of a namespace diagram, recorded before the change, pins the
output, and a test pins namespace equality.

Breaking changes:
- Namespace no longer derives from Slice. Code that used a Namespace
  as a Slice, or used Identifier, NameSpace, CountOfAsteriskInPattern
  or ContainsNamespace() on it, no longer compiles.
- Namespaces can no longer be passed to the slice overload of
  WithDependenciesFrom or to WithDependenciesFromFocusOn, nor to
  WithDependenciesFromSlices in the fluent API. Use the namespace
  overload of WithDependenciesFrom or WithDependenciesFromNamespaces.

Signed-off-by: Alexander Linne <alexander.linne@tngtech.com>
@alexanderlinne
alexanderlinne force-pushed the stop-deriving-namespace-from-slice branch from bf4efd7 to 72203f8 Compare November 14, 2026 08:51

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants