On 2013-17-09 18:55, Andy Parker wrote:
On Tue, Sep 17, 2013 at 9:35 AM, Henrik Lindberg
<[email protected] <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".
- 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.
