Structured Software Architecture
Eliminating Namespace Issues using Nested and Layered Part Composition 2026-04-09
There are 3 Parts on this diagram. The Container part has kind (type) “P”. It contains 2 child parts, one of kind “A” and another of kind “B”. The Container “P”, also, contains one wire, drawn as an arrow between ports “x” and “y”.
Container Part “P” sees
Part of kind A and its port A.x
Part of kind B and its port B.y
wire [“across”, A.x, B.y]
Container “P” cannot see
A.a, A.b, A.c, A.d, A.e, A.f (any of the entities inside of A)
B.s, B.t, B.u, B.v (any of the entities inside of B)
Part A does not see part B, nor B.y, nor any of the named entities inside of B
Part B does not see Part A, nor A.X, nor any of the named entities inside of A
Parts P, A, B have one (and only one) input queue, each
Parts P, A, B have one (and only one) output queue, each
Sending an Output Message (Mevent)
1. A sends message “Hello” to its own port “x”. (N.B. to its own output port, not to B’s y port).
2. The Mevent send consists of mapping the output mevent of A into an input mevent for B. P performs this mapping then enqueues the new message onto B’s input queue
Discussion
Expressing the following rules in English makes them appear to be more complicated than necessary. The basic idea is essentially “do not colour outside of the lines” - an idea that is taught to children at an early age in pre-school.
Parts are essentially “black boxes”.
Parts are nested and layered and isolated from one another. Parts cannot reach in across the boundaries of other parts and access their internals. Wires (arrows) can only connect ports (note the spelling, port not part) to other ports. Wires cannot cross edges of parts (nor ports).
Wires (arrows) are entirely contained within container parts. Wires are owned by container parts, not children of the containers. A child cannot refer sideways to any other sibling part. A child cannot refer upwards to a parent part.
A child part can be either a Container part or a Leaf part. The parent cannot know how the child is implemented and whether the child is a Container or a Leaf. If a child is implemented as a Container, it can only refer to its own, direct children and its own wires.
This (recursive) nesting hides internal namespaces. A Container part can only see its children’s kinds (types) and the external-facing ports provided by each child [akin to “pins” on hardware ICs]. Since each part, whether Container or Leaf, is otherwise opaque, children’s names do not leak out of Container parts.
Namespacing issues are restricted in scope. Internal names do not leak out to enclosing parts. Each layer sees only a small number of names.
Parts, themselves, do not have explicit names (the “compiler” tracks each part individually using graphical coordinates).
There are no “name clashes” due to part kinds. A container can contain many parts of the same kind (P, A, B in the above example), since the underlying system differentiates parts by position instead of by name or kind.
There are no “name clashes” due to port names, since wires carry output to input mapping information. [Actually, source to sink mapping - I choose to skip over this nuance here].
See Also
Email: ptcomputingsimplicity@gmail.com
Substack: paultarvydas.substack.com
Videos: https://www.youtube.com/@programmingsimplicity2980
Discord: https://discord.gg/65YZUh6Jpq
Leanpub: [WIP] https://leanpub.com/u/paul-tarvydas
Twitter: @paul_tarvydas
Bluesky: @paultarvydas.bsky.social
Mastodon: @paultarvydas
(earlier) Blog: guitarvydas.github.io
References: https://guitarvydas.github.io/2024/01/06/References.html