Child Part vs. Subpart

Posted Dec 29, 2025 | ~1 minute read

At first, child part and subpart might seem like synonyms. Throughout the source code of the Kireji Framework, there are references to both. That's not a mistake or a result of loosely-defined syntax.

The difference is actually very simple: subparts are concrete child parts and therefore not abstract child parts. All subparts are child parts, but not all child parts are subparts.

Abstract vs. Concrete Parts

In the Kireji project, abstract parts are the opposite of concrete parts. Their meaning is essentially the same as abstract classes and concrete classes in object-oriented programming. That is, abstract parts are stateless blueprints for "real," stateful parts. They can be extended to create those real parts but they don't have a state by themselves. They also don't participate in the framework's event loop.

All parts exist somewhere in the hierarchy of domains so that all parts can have a unique, meaningful name while coexisting in a single namespace. A part has a dedicated domain namespace and all of its child parts form their own subdomain namespaces. Therefore, all parts (other than the domain name root) are a child of some other part. Yet, from a state space perspective, abstract child parts aren't true subparts of their parent because they remain invisible to their parent's state handling.

This pattern allows us to define parts that describe complex handling of views and/or arithmetic so that extension parts don't need to be aware of those details and can instead focus on their own exclusive purpose. This prevents code repetition when defining parts which in turn reduces the risk of errors and the overall size and complexity of the code base.

For example, the part mix.abstract.parts is a child part of the part abstract.parts in that it exists within its parent namespace. Yet, it is not a subpart of abstract.parts. It provides a generic implementation of a cartesian product space that uses its subpart spaces as its factors. The abstract mix doesn't have any defined factors because these will vary from implementation to implementation. As a result, the abstract mix doesn't have enough information to define any actual cartesian product space on its own.

Parts act like Arrays of their Subparts

One of the core desires I had for parts and their subparts was to be able to simply say:

for (const subpart of part) {
 // Do something with subpart
}

This was achieved by providing each part with an iterator over its subparts. This ensures that we can intuitively loop over all of the concrete child parts that contribute to the parent part's state without accidentally performing arithmetic on an abstract part that happens to exist in the same namespace.

It is possible to loop over all child parts, but this is less common and so it requires a more verbose solution, such as:

for (const subdomain of part.subdomains) {
 const childPart = part[subdomain]
 // Do something with childPart
}

Conclusion

So there you have it. Subparts are concrete child parts. Feel free to browse around in the Kireji Part Viewer to get hands-on experience comparing subparts to abstract parts.