Awkward factorization of realization results #116

New issue

Open

opened 2025-08-29 08:24:48 +00:00 by Vectornaut · 0 comments

Vectornaut commented

2025-08-29 08:24:48 +00:00

Member

As of pull request #114, the application gets all the configuration information it needs from the history field of the Realization structure that realize_gram returns. The config field in Realization::result is never read. In fact, the config field is never read from any ConfigNeighborhood structure.

The config field is still used in tests and examples, however, so we compile it conditionally to avoid a dead code warning.

If the history rewind feature ends up being a long-term part of the application, we should refactor the Realization structure to avoid this awkward orgnization. Since this feature is engine-dependent, however, I don't think we should plan for its long-term persistence yet.

As of pull request #114, the application gets all the configuration information it needs from the `history` field of the `Realization` structure that `realize_gram` returns. The `config` field in `Realization::result` is never read. In fact, the `config` field is never read from any `ConfigNeighborhood` structure. The `config` field is still used in tests and examples, however, so we compile it conditionally to avoid a dead code warning. If the history rewind feature ends up being a long-term part of the application, we should refactor the `Realization` structure to avoid this awkward orgnization. Since this feature is engine-dependent, however, I don't think we should plan for its long-term persistence yet.