Friends -- As of 30da528e9c8ac345d1020d1cbeee02598174a3c5 we put this intentionally back to the 2.7 behaviour. Because both
(a) the change crept in as a side-effect of other code changes, not as a deliberate language design choice -and- (b) we are not providing a simple (sigil or keyword) workaround for people to preserve the behaviour they've written around. are true here, I'm convinced it's not a good change. After this commit, the sample code in Erik's update 1 works as expected, as do the other cases I'm able to test. Thanks for your feedback. Eric Sorenson - [email protected] PuppetConf'12 - 27-28 Sep in SF - http://bit.ly/pcsig12 On Friday, September 14, 2012 11:31:17 AM UTC-7, Eric Sorenson wrote: > > Hi, there's an issue that came up recently in the 3.0RCs -- Big thanks to > Erik Dalén for reporting it in #16221 -- that involves a behaviour change > to part of the DSL. In a nutshell, this code: > > define foobar ($param='Hello world') { > notice($param) > } > foobar { 'test': param => undef } > > in 2.7, causes 'Hello world' in the notice. In 3.x, it's nothing. As I > said in the bug, this seems more correct to me -- I've overriden the > default with an explicit 'undef', taking off the default. The same thing > goes for invoking parameterised classes with undef arguments, which is > perhaps more ambiguous (example from matthaus): > > class toplevel ( > $maybe = false, > $optional = undef ) { > if ($maybe) { > class { toplevel::secondlevel: optional => undef } > } > } > > In order to make use of the default for the `optional` parameter in > toplevel::secondlevel, you'd now need to either test in `toplevel` whether > `$optional` was passed into it, or have toplevel::secondlevel use an > `$optional_real` value inside it, similar to what's commonly done to append > to defaults that are array values. > > The closest thing to documentation around this suggests the new behaviour > is what's intended < > http://docs.puppetlabs.com/puppet/2.7/reference/lang_classes.html#overriding-resource-attributes>: > > > > You can remove an attribute’s previous value without setting a new one > by overriding it with the special value undef: > > class base::freebsd inherits base::unix { > File['/etc/passwd'] { > group => undef, > } > } > > So, I'm trying to determine whether this is a widespread pattern or an > edge-case. Do you expect 'param=>undef' to be the same as not specifying > param at all, or for the receiver to "see" the undef? > > Eric Sorenson - [email protected] > PuppetConf'12 - 27-28 Sep in SF - http://bit.ly/pcsig12 > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/MByhP6uHbwQJ. 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-users?hl=en.
