Skip to content

Impose an ordering on the specification #71

@samwyse

Description

@samwyse

When studying a specification, it is helpful if the various portions have a natural ordering, such that each portion only depends upon the successful understanding (or implementation) of the preceding portions, and not on the implementation of any succeeding portions. Unfortunately, there is a dependency loop between the 'interpolation' and 'sections' portions of the specification. Specifically, the five tests 'Dotted Names - Basic Interpolation', 'Dotted Names - Triple Mustache Interpolation', 'Dotted Names - Ampersand Interpolation', 'Dotted Names - Initial Resolution' and 'Dotted Names - Context Precedence' of the 'interpolation' portion assume that the 'sections' portion has been implemented. These tests should be moved to the 'sections' portion. Modified versions of the first three can left in the 'interpolation' portion by making them more like the Dotted Names - Arbitrary Depth interpolation test.

Once the portions can be ordered, it would also be helpful to include information about that in the specification itself, by adding a key to the top level. Several possible names suggest themselves for this key; I will use 'depends_upon' but 'assumes', 'requires' or 'uses' would also be good names.

The 'interpolation' portion, being the base, would include this:

depends_upon: []

The 'comments' and 'sections' specs would include this:

depends_upon: ['interpolation']

The 'delimiters', 'inverted' and 'partials' portions would include this:

depends_upon: ['sections']

Finally, the '~lambdas' portion would include this:

depends_upon: ['inverted']

With this in place, a topological sort will produce an ordering. Note that each section defines a list of prerequisites, even though the current specs only demand one each; also note that although a topological sort can figure things out, you may want to include all prerequisites in the list, not just the immediate predecessor.

Metadata

Metadata

Assignees

No one assigned

    Labels

    infrastructurestructural changes not affecting test content

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions