-
Notifications
You must be signed in to change notification settings - Fork 97
Description
If I am not mistaken, LQOI add supports for names even if the solver does not support names.
It does not really match the MOI philosophy of not adding features on the wrapper if that does not rely on a support provided by the solver.
If we make an exception for names that means that all solver wrappers should implement names but that's unscalable.
One reason for LQOI to support names is that LQOI solvers supports_default_copy_to so support for names is the only thing missing to allow them to be used in direct mode without cache.
So should we say that all solver wrappers that supports_default_copy_to should implement names ? That's also probably unscalable to maintain.
Since implementation of names is always the same we could do one of the following:
- Creates macros for adding the necessary fields in the optimizer struct and have an abstract type
AbstractOptimizerWithNamefor optimizers with this field (or a trait maybe). Then we can implement names in MOI and there is no need to add a method for every implementation. - Add a MOI layer that adds support for names (it basically lets all MOI calls go through except the ones about names that it handles). It is kind of like UniversalFallback but only for names (you don't want to add an UniversalFallback on top of an optimizer since it will silently hide unsupported constraints, unsupported attributes, ...).