Skip to content

Documentation ordering is registration-dependent instead of declaration-ordered #92

Description

@orting

Summary

Documentation parameter/sample ordering is still unstable because unordered frame entries are emitted in registration-dependent symbol/map/set order rather than in declaration order.

Problem

In the generated reference manual, many sections still drift even when semantics are unchanged. This shows up in:

  • parameter/member lists for models and submodels
  • sample/default parameterization blocks (< (...) (...) >)
  • repagination and page-reference churn caused by those reordered sections

Examples observed during explicit-registration verification include AOM/SMB/SOM sections and some hydraulic model sections.

Root cause

When a frame does not provide an explicit frame.order(...), the documentation path eventually falls back to unordered Frame::entries() data.

Those entries are sourced from containers keyed by symbol, and symbol::operator< is based on symbol ID creation order rather than the order parameters were declared in load_frame() / DeclareModel syntax code.

That means documentation order can depend on registration timing instead of source declaration order.

Desired behavior

The default order should be declaration order:

  • preserve the order members are declared in DeclareModel / load_frame() code
  • use that as the fallback documentation order when frame.order(...) is not set
  • keep frame.order(...) as an explicit override for cases that need custom presentation

This should apply to both:

  • documented parameter/member lists
  • printed sample/default parameterization blocks

Why declaration order

Declaration order is a better semantic default than alphabetical order because it preserves the author’s intended grouping and presentation in the syntax definition.

Likely implementation direction

  • Preserve first-seen insertion order in Frame
  • Use that preserved declaration order when iterating entries unless an explicit frame.order(...) is present
  • Handle inherited/base members carefully so base declaration order is preserved and derived members append naturally

Relevant code

  • src/object_model/frame.C
  • include/object_model/frame.h
  • include/object_model/symbol.h
  • src/object_model/symbol.C
  • src/programs/program_document.C

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions