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

未關閉
  • 哪裡不對？
#413 1 則留言 0 個 reaction 已指派 1 人 在 GitHub 檢視

維護者通常 1 天內回覆

@ocots 已經在處理了。

開始於 2026年11月7日。

評估

這個 Issue 還沒有評估資料。

描述

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.

主要語言
Julia
星號
13
分支
1
平均合併
3 小時 9 分鐘
30 天內合併 PR
47

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

control-toolbox/OptimalControlProblems.jl 的其他 Issue

查看 control-toolbox/OptimalControlProblems.jl 的全部 Issue

相似的 Issue

更多 Julia Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。