On Tue, Sep 17, 2013 at 10:13 AM, Henrik Lindberg < [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 <[email protected]><mailto: >> henrik.lindberg@**cloudsmith.com <[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. > > - 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 > puppet-dev+unsubscribe@**googlegroups.com<puppet-dev%[email protected]> > . > To post to this group, send email to [email protected]. > Visit this group at > http://groups.google.com/**group/puppet-dev<http://groups.google.com/group/puppet-dev> > . > For more options, visit > https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> > . > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *Join us at PuppetConf 2014, September 23-24 in San Francisco* -- 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.
