Issue #15329 has been updated by Henrik Lindberg.
Reid Vandewiele wrote:
> 1. What purpose would having a `nil` keyword serve in the DSL? What would it
> be used for?
That was not what I proposed. I think it is enough to have a simple one value
"nothingness", and the symbol "undef" works just as fine as any other,
especially as it already exists in the puppet language.
> 2. How would removing `undef` in favor of more syntax ("fat comma") make the
> DSL better?
Proposal is not to remove the undef literal.
The problem is that it is unclear where "nothing" becomes "antimatter" (i.e. no
longer a value that should be passed, but something that has semantics with the
meaning "use the default", or "act as if this was not assigned").
Currently, if you pass undef to a parameter with a default, it will pick the
default, and not pass on the undef. I suggest that it should pass undef as a
value that overrides the default (we are after all passing something). The only
mechanism that is missing is to be able to conditionally set what is being
passed (if you got the value as a parameter/variable, and do not know what it
is you can't simply skip using it) i.e. you control if you want to pass on the
ability to "undef" something, or if you want to use a default value.
In your inheritance example you expect the undef of file content to mean that
it does not have the content "managed" as declared in the class the child
inherits. (Here undef is used as a value; assigning "nothing" to content).
If you try the same and pass "undef" to a define, and the define has a variable
with default = "managed", you would instead get the value "managed". (I.e.
undef is not a value). This is confusing IMO. And this prohibits passing
"undef" through several layers of logic.
My proposal is simply that the meaning of "nothing" should be determined where
it is applied to something - is it a value like any other, or does it mean "do
not assign"? You can currently easily control this everywhere except in the
statements on the form "type { param => value }", and my proposal was to fix
that.
OTOH - if there is a desire to have two different values; "no value" vs. "use
the default/don't do it/use what is there" we need two different literals.
(Which I think is more complex). Problem now is that both of these concepts are
rolled up into one and used inconsistently.
Hope that helps explain what I am proposing.
----------------------------------------
Bug #15329: Puppet lacks a proper "undefined" value
https://projects.puppetlabs.com/issues/15329#change-78309
Author: Pieter van de Bruggen
Status: Accepted
Priority: Normal
Assignee: Henrik Lindberg
Category:
Target version:
Affected Puppet version:
Keywords: backlog
Branch:
$y = undef
notice($y == "") # true
notice($x == $y) # true
notice($x == "") # true
Recent changes in the Puppet DSL made equality commutative (good!), but in
doing so broke work-arounds for actually testing for the difference between an
undefined and "empty" value. The most logical fix would be to equate Puppet's
`undef` with Ruby's `nil`.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
