On 2013-23-09 15:38, Andy Parker wrote:
On Tue, Sep 17, 2013 at 10:13 AM, Henrik Lindberg
<[email protected] <mailto:[email protected]>>
wrote:
On 2013-17-09 18:55, Andy Parker wrote:
On Tue, Sep 17, 2013 at 9:35 AM, Henrik Lindberg
<henrik.lindberg@cloudsmith.__com
<mailto:[email protected]>
<mailto:henrik.lindberg@__cloudsmith.com
<mailto:[email protected]>>>
wrote:
On 2013-17-09 5:44, Henrik Lindberg wrote:
On 2013-16-09 19:28, Andy Parker wrote:
On Mon, Sep 16, 2013 at 7:58 AM, Henrik Lindberg
So we just talked about this on IRC. I think the
outcome was:
* We agree that undef is really messed up right now
* Variable references should be strict
* A few of the other changes mentioned here
might be good
* We differ on the correctness of class/resource
parameters being
given undef resulting in the default value
I think that the correct behavior for undef being
passed is
to result in
the default value. From what I've seen and heard
about how
it gets used,
this is actually the more desirable behavior for
the use
cases that are
commonly encountered.
I think that is a reasonable starting point, and it is
so much
better
than the current handling of undef.
Will use this when experimenting with future evaluator.
Will see
what we
learn from that.
.... and then I realized why I do not want an assignment of
undef to
mean "no assignment"/"set default".
If/when resource attributes are typed it is then not
possible to set
them to 'no value' unless that is their default value. When
everything is String, an empty string serves as "no value",
but for
numbers there is no equivalence.
I don't follow. Are you saying that a value of undef is not
compatible
with the String type? Normally undef is a subtype of all types
and so
that is allowed.
If you have a resource with an attribute that is an Integer, and it
has a default value of '0', and you want to set it to undef. How
would you do that? You cannot do this:
my_resource { 'xxx':
the_int_attribute => undef
}
i.e. there is no value you can use that sets the_int_attribute to
undef/nil/no-value/unknown.
For variables it naturally works, because there is no special
handling that makes undef behave as "do not set value".
What you are describing has little value in the puppet DSL. I think I
understand what you are getting at, but it is not a feature that the
language needs as far as I am concerned. I am willing to be convinced
otherwise, but I would need specific examples in which the best (or
only) way of achieving the desired result is via undef being passed as a
parameter where the parameter has a default value.
The scenario where this matters is if you want to unset a value
set by default. I.e. when a type/object has an optional int attribute
(is allowed to be nil). It starts its life being nil, if we do not set
the value, it is set to what is stated as its default/inherited. You can
set it to some other int value, 0, -1, etc. but not unset it.
# sets default value to 1
Some_type {
an_int => 1
}
class foo {
$x = undef
# do not want the default value, want nil instead
some_type { 'a':
an_int => $x
}
}
This concern has no/very little impact in Puppet 3x because puppet only
deals with strings and you can set empty string.
I agree that it is a corner case, and one that is not terribly important
since if you find needing this, the inherited logic/the default setting
should really not have been made in the first place.
I am willing to accept that it is impossible to unset an attribute.
If we do find we do need it, I suggest that we then implement it as an
operator e.g. '!=>' to mean 'unset if undef' (as opposed to the regular
'=>' which means 'do not change/set if undef'.
# sets default value to 1
Some_type {
an_int => 1
}
class foo {
$x = undef
# do not want the default value, want nil
some_type { 'a':
an_int !=> $x
}
# want the default if $x is undef
some_type { 'b':
an_int => $x
}
}
This way, the common case (what people seem to expect (that assigning
undef gives you the default/inherited value) is supported without
change, while it is still possible to get unset semantics without use of
yet another kind-of-nil magic value (which I do not like at all).
Although I am accepting the inconsistency (nil/undef is not a value when
assigned to an attribute), I still think that this is backwards. If we
change so that variable assignment of undef does not give them their
outer scope value, but actually sets them to undef. Why then expect the
"old" behavior from attributes?
i.e. I would rather see the optional assign, than the optional do not
assign...
# sets default value to 1
Some_type {
an_int => 1
}
class foo {
$x = undef
# do not want the default value, want nil
some_type { 'a':
an_int => $x
}
# want the default if $x is undef
some_type { 'b':
an_int ?=> $x
}
}
Regards
- henrik
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
