Model: canget objective function of the wrong type

[tkoolen]

Because of

https://github.com/JuliaOpt/MathOptInterfaceUtilities.jl/blob/532ebec78b8b8e35dbf7e7443ddcdb663ff279cf/src/model.jl#L225-L231

and
https://github.com/JuliaOpt/MathOptInterfaceUtilities.jl/blob/532ebec78b8b8e35dbf7e7443ddcdb663ff279cf/src/model.jl#L171

you can set a quadratic objective, ask if you can get a SingleVariable objective (why yes you can!) and then when you call get with ObjectiveFunction{SingleVariable} you receive a ScalarQuadraticFunction.

By the way, I was expecting this to be implemented with three different fields, not just one field with Union type; I guess this is a temporary solution?

[mlubin]

This is a bug, holdover from before ObjectiveFunction had a type parameter.

[blegat]

By the way, I was expecting this to be implemented with three different fields, not just one field with Union type; I guess this is a temporary solution?

Why using three different fields ? There should be only one objective function.

[tkoolen]

Just like there are separate fields for e.g. SingleVariable and ScalarAffineFunction constraints. Sure, there can be multiple of those and only one objective function, but you're losing type stability with the Union type, which makes me ask why the ObjectiveFunction attribute should be parameterized at all. But come to think of it, I guess a better approach would probably be to use use return type annotations in the get functions to regain type stability. However, that's currently not the case.

[blegat]

If several fields are used, we need to check each time which of them is not nothing, I am not sure that would be faster. Since there is only one objective, performance is less critical than for constraints where a small performance loss at each function can become significant with thousands of constraints.

I guess a better approach would probably be to use use return type annotations in the get functions to regain type stability. However, that's currently not the case.

That's a good idea