It would seem appropriate to me to be able to delay the actual creation of variables as long as possible, or at least their domain, so as to be in a better position to determine the most appropriate format.This is particularly true when creating models using modelling languages (such as MiniZinc or XCSP3) or when using non-experts. See for instance minizinc/2029/liner-sf-repositioning/fm3_0.mzn.
With the use of LCGs, the question also arises because the behaviour of enumerated and bounded variables is different. In particular, bounded variables do not allow you to designate an instantiation literal. This poses a problem when this type of variable is used in table constraints, for example.
Ideally, it should be possible to "promote" a variable. In practice, it should be possible to replace a variable with a more suitable one. In Java, this is not natively possible (unlike SmallTalk or C++ and pointer swapping). It requires the implementation of a wrapper around the variable.
In early version of choco-solver, a distinction was made between variables and their domain (as an object). The variable itself was a wrapper around its domain. Maybe that should be considered anew.
From a software engineering point of view, this doesn't change much. From a performance point of view, however, this introduces an extra layer in the call stack. As in choco-solver, failures are handled by raising an exception, this additional layer can ultimately have an impact on performance, as the distance between the exception and the catcher is greater (https://shipilev.net/blog/2014/exceptional-performance/ or https://www.baeldung.com/java-exceptions-performance).
It would seem appropriate to me to be able to delay the actual creation of variables as long as possible, or at least their domain, so as to be in a better position to determine the most appropriate format.This is particularly true when creating models using modelling languages (such as MiniZinc or XCSP3) or when using non-experts. See for instance minizinc/2029/liner-sf-repositioning/fm3_0.mzn.
With the use of LCGs, the question also arises because the behaviour of enumerated and bounded variables is different. In particular, bounded variables do not allow you to designate an instantiation literal. This poses a problem when this type of variable is used in table constraints, for example.
Ideally, it should be possible to "promote" a variable. In practice, it should be possible to replace a variable with a more suitable one. In Java, this is not natively possible (unlike SmallTalk or C++ and pointer swapping). It requires the implementation of a wrapper around the variable.
In early version of choco-solver, a distinction was made between variables and their domain (as an object). The variable itself was a wrapper around its domain. Maybe that should be considered anew.
From a software engineering point of view, this doesn't change much. From a performance point of view, however, this introduces an extra layer in the call stack. As in choco-solver, failures are handled by raising an exception, this additional layer can ultimately have an impact on performance, as the distance between the exception and the catcher is greater (https://shipilev.net/blog/2014/exceptional-performance/ or https://www.baeldung.com/java-exceptions-performance).