You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An undefined variable produce a warning. Later on, a value can be assigned to this variable, which somewhat clash with the fact that variables are immutable.
The following show illustrate this issue:
ifdefined('$foo') {
warning("A: foo=${foo}")} else { warning("A: foo is not defined")}$foo = 'value'if defined('$foo') { warning("B: foo=${foo}")} else { warning("B: foo is not defined")}
Applying this catalog produce:
Warning: Scope(Class[main]): A: foo is not defined
Warning: Scope(Class[main]): B: foo=value
The above example is intended to illustrate the issue. In the wild, this problem is often found when a module provide a defined type which has parameters that default to the value of a variable in another class of the module, for example:
Instead of immediately producing a warning if a variable is used (or returning false when testing if the variable is defined), stopping evaluation of the current statement and re-evaluating it later may help have a better behavior.
Describe Alternatives You've Considered
If deferring evaluation is not possible, assigning a value to a variable which has already resolved as undefined should not be possible and raise an error.
The text was updated successfully, but these errors were encountered:
Implementing that would completely change the order in which defines are evaluated and would most likely break a lot of existing code. There have been proposals in the past to make the puppet language completely functional and declarative. The puppet language is not declarative (although the resulting catalog is) and changing the overall order of evaluation would be too painful for everyone.
Use Case
An undefined variable produce a warning. Later on, a value can be assigned to this variable, which somewhat clash with the fact that variables are immutable.
The following show illustrate this issue:
Applying this catalog produce:
The above example is intended to illustrate the issue. In the wild, this problem is often found when a module provide a defined type which has parameters that default to the value of a variable in another class of the module, for example:
Describe the Solution You Would Like
Instead of immediately producing a warning if a variable is used (or returning false when testing if the variable is defined), stopping evaluation of the current statement and re-evaluating it later may help have a better behavior.
Describe Alternatives You've Considered
If deferring evaluation is not possible, assigning a value to a variable which has already resolved as undefined should not be possible and raise an error.
The text was updated successfully, but these errors were encountered: