[Dev] Split src into submodules (ct-conventions MOD1, MOD2), keeping the public exports

Aberta
  • Algo errado?
#413 1 comentário 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@ocots já está trabalhando nisso.

Desde 7/11/2026.

Avaliação

Esta issue ainda não foi avaliada.

Descrição

dev

Agents: read the guide for agents in #310 first (order, difficulty, how to claim an issue, working method).

Goal

Split src/OptimalControlProblems.jl (683 lines: modelings, discovery of the problems, metadata schema and loading, references, parameters, initial guesses, aliases of CTModels) into submodules, one per responsibility, following ct-conventions (MOD1, MOD2), so that the package file only declares. Submodules also hide what users do not need: internals stay reachable as OptimalControlProblems.<Submodule>.f and no longer appear at the top level.

Decisions (maintainer, 2026-11-07)

  1. The package keeps its exports. MOD8 (no top-level export) is written for the internal CT* packages; OptimalControlProblems is user-facing, like OptimalControl.jl. using OptimalControlProblems; beam(OptimalControlBackend()) keeps working. No breaking change of the public API.
  2. Problems and public functions live in submodules that export them, and the package re-exports them. The public API is the union of the submodule exports re-exported by the package; what a submodule does not export stays qualified (OptimalControlProblems.Metadata._references…). The extensions keep defining methods on the same functions (OptimalControlProblems.beam is the same function as OptimalControlProblems.<Submodule>.beam).
  3. Wait for #408 (documentation rewrite): its API reference is generated per module (docs/api_reference.jl). Start only once #408 is merged.

Proposed split (to confirm when taking the issue)

Submodule What moves there
Modelings/ AbstractModelBackend, JuMPBackend, OptimalControlBackend, OptimalControlScalarizedBackend, MODELING_SPECS and what derives from it
Catalogue/ discovery of the problems (make_list_of_problems, PROBLEM_NAMES), the problem functions (beam…), problems, status, the draft warning
Metadata/ schema, loading of ext/MetaData/, problem_metadata, grid_size_data, parameters_data, initial_guess_data, merge
References/ SAME_SOLUTION, loading of ext/MetaData/references/, reference_objective, solution_kind, the analytic solutions (solutions.jl); later the typed references of #409
Problems/ Problem (problem.jl), model, initial_guess, metadata, solution, the aliases of CTModels (state, control, objective…)

Order of the submodules follows their dependencies (MOD7, one-way). The precompilation dependencies (Base.include_dependency on ext/ and the reference files) move with the code that reads them.

Order

  • After #408 is merged.
  • Before part 2 of #409, which adds AbstractReference and its types: they go directly into References/. Part 1 of #409 (#412) only touches test/ and is independent.

Done when

  • src/OptimalControlProblems.jl only declares: imports, includes of src/<Name>/<Name>.jl, using .<Name>, re-exports.
  • Each submodule follows MOD1/MOD2, exports its public part.
  • names(OptimalControlProblems) is unchanged (a test compares it with the list before the move, generated, not hand-written), and every internal used by the tests, tools, extensions and docs is reached through its submodule.
  • Extensions, tools/, test/ and docs/ updated; full test suite and documentation build green.
  • A README in src/ saying what each submodule holds (developer documentation lives next to the code, #307).

Related: #409 (typed references), #408 (documentation), #310.

Linguagem predominante
Julia
Estrelas
13
Forks
1
Merge médio
3h 9min
PRs com merge (30d)
47

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de control-toolbox/OptimalControlProblems.jl

Todas as issues de control-toolbox/OptimalControlProblems.jl

Issues semelhantes

Mais issues de Julia

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.