Hierarchy is not a property

There are many cases where an item contains a property that defines its location inside a hierarchy:

• In HTML a header element defines its own location in the (assumed) hierarchy of headers: an H1 header is "higher" than an H2 header.
• Latex sections also define their own level: there are sections, subsections and subsubsections.
• Java source files define their own package, and the information is usually redundantly reflected in the directory hierarchy, too.

This is an antipattern. The location in a hierarchy is not a property of the contained object. Instead, the location in a hierarchy is simply defined by the location in a hierarchy.

If the parent-child relationship is defined only by an attribute in the child object, this is not a problem. One-to-many relationships in SQL are typically defined like this. (Technically references are often stored in both ends of a relationship, especially in volatile run-time objects, but this is just an optimization, hidden under the hood.)

The problem in all the examples above is that the hierarchy is defined both by an attribute of the child and the location of the child in relation to other objects. This redundancy causes problems when the structure needs to be changed: the object needs to be both moved and changed.

The article language I wrote in ngrease is an abstraction of HTML and Latex, but in it sections are defined as a nested hierarchy. This makes writing and restructuring painless, especially if each section is defined in a separate file, included by its parent: Only one layer thinking is needed when writing a section, and the article can be restructured simply by moving section references (the "include" expressions), without any need to touch the referenced section definitions.