Improve @def

[jbcaillau]

• o = @def expr in addition to @def o expr
• @def! o expr to update (add feature) existing o

[jbcaillau]

@ocots side notes:

• would be possible to provide an @def! macro to add things to a previously created ocp (with the correct type according to time / variable dependences)
• not completely coherent with the fact that with the current global (= all at once definition) we infer these dependences (hence the type)

[ocots]

@ocots side notes:

• would be possible to provide an @def! macro to add things to a previously created ocp (with the correct type according to time / variable dependences)
• not completely coherent with the fact that with the current global (= all at once definition) we infer these dependences (hence the type)

You could simply redo all the parsing since you have the model in ocp.model_expression.

https://github.com/control-toolbox/CTBase.jl/blob/main/src%2Ftypes.jl#L1157

We could use this here: https://control-toolbox.org/OptimalControl.jl/dev/tutorial-basic-example.html#State-constraint

[jbcaillau]

You could simply redo all the parsing since you have the model in ocp.model_expression.

https://github.com/control-toolbox/CTBase.jl/blob/main/src%2Ftypes.jl#L1157

right, as you did for the REPL. but this only works for an ocp first defined abstractly, while it could be first defined using the functional API. BTW, I more and more think that we should keep the functional API more or less internal.

We could use this here: https://control-toolbox.org/OptimalControl.jl/dev/tutorial-basic-example.html#State-constraint

Yes. Always nice to avoid code duplication. There are other ways, though (working on expressions, strings, then parsing...) Keeping hereafter for further reference #235