This is quite valuable. I tend to use "" (the empty string) for this and check against that in my logic.
It would be much cleaner to just be able to set something to undef and have it "do the right thing". Trevor On Mon, Sep 23, 2013 at 1:31 PM, Henrik Lindberg < [email protected]> wrote: > On 2013-23-09 15:38, Andy Parker wrote: > >> On Tue, Sep 17, 2013 at 10:13 AM, Henrik Lindberg >> <henrik.lindberg@cloudsmith.**com <[email protected]><mailto: >> henrik.lindberg@**cloudsmith.com <[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:henrik.lindberg@**cloudsmith.com<[email protected]> >> > >> <mailto:henrik.lindberg@__clou**dsmith.com<http://cloudsmith.com> >> >> >> <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. >> >> >> > 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 > 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> > . > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- 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.
