Parser: prefix functional primitives

[jbcaillau]

To avoid conflicts with other packages (ex. ExaModels), prefix before macro expansion: e.g. OptimalControl.constraint!(...)

[ocots]

Attention, une fois le using OptimalControl fait, il faudra qualifier (ou préfixer) avec OptimalControl.

julia> using OptimalControl

julia> methods(CTBase.constraint!)
ERROR: UndefVarError: `CTBase` not defined
Stacktrace:
 [1] top-level scope
   @ REPL[2]:1

julia> methods(OptimalControl.constraint!)
# 1 method for generic function "constraint!" from CTBase:
 [1] constraint!(ocp::CTBase.OptimalControlModel{T, V}, type::Symbol; rg, f, lb, ub, label) where {T<:CTBase.TimeDependence, V<:CTBase.VariableDependence}
     @ ~/.julia/packages/CTBase/fDnnG/src/model.jl:550

julia> using CTBase
 │ Package CTBase not found, but a package named CTBase is available from a registry. 
 │ Install package?
 │   (@v1.10) pkg> add CTBase 
 └ (y/n/o) [y]: y
   Resolving package versions...
    Updating `~/.julia/environments/v1.10/Project.toml`
  [54762871] + CTBase v0.11.3
  No Changes to `~/.julia/environments/v1.10/Manifest.toml`

julia> methods(CTBase.constraint!)
# 1 method for generic function "constraint!" from CTBase:
 [1] constraint!(ocp::OptimalControlModel{T, V}, type::Symbol; rg, f, lb, ub, label) where {T<:TimeDependence, V<:VariableDependence}
     @ ~/.julia/packages/CTBase/fDnnG/src/model.jl:550

(@v1.10) pkg> rm CTBase
    Updating `~/.julia/environments/v1.10/Project.toml`
  [54762871] - CTBase v0.11.3
  No Changes to `~/.julia/environments/v1.10/Manifest.toml`

(@v1.10) pkg> 

[jbcaillau]

✅ @ocots right. prefix by OptimalControl (functional primitives are exported, until now).

[jbcaillau]

@ocots second thoughts: what is the good solution here?

• the user will use OptimalControl, not CTBase
• we still need to be able to test the abstract inside CTBase (we could import OptimalControl for this, though...)

Bref. Is it OK to import CTBase from within OptimalControl so that the user generated code like CTBase.state!(...) is OK?

[ocots]

@ocots second thoughts: what is the good solution here?

• the user will use OptimalControl, not CTBase
• we still need to be able to test the abstract inside CTBase (we could import OptimalControl for this, though...)

Bref. Is it OK to import CTBase from within OptimalControl so that the user generated code like CTBase.state!(...) is OK?

This is the problem. I think that it won't work :-(

[jbcaillau]

@ocots two ways?

• generate code prefixed by OptimalControl, and import OptimalControl in CTBase.jl tests (remains internal), thanks to the fact that OptimalControl.jl reexports the requested getters
• another way would be to prefix à la main the CTBase routines by creating aliases such as OptimalControl_time!(...), etc.

NB.

• also update
  

  CTBase.jl/src/CTBase.jl

  Line 259 in 281285e

  export __OCPModel # redirection to Model to avoid confusion with other Model functions from other packages. Due to @def macro

• and probably the same thing in OptimalControl.jl

[ocots]

For OptimalControl.jl its here: https://github.com/control-toolbox/OptimalControl.jl/blob/main/src%2FOptimalControl.jl#L55