On Mon, Sep 17, 2012 at 11:58 AM, Eric Sorenson <[email protected]> wrote: > Aaron -- could you distill this down to a code sample? Unless I'm > misunderstanding, it sounds like your case is slightly different to the ones > I posted. Thanks.
I recognise the case; this is a different use and, as far as I understand, shouldn't be changed. (It is also consistent with how the *new* behaviour of undef vs parameter defaults works. :) > On Friday, September 14, 2012 3:29:05 PM UTC-7, Aaron Grewell wrote: >> >> I'm using the current behavior in inherited classes to unset parameters >> set by the parent class. If that no longer works it will definitely impact >> my code. >> >> On Sep 14, 2012 11:31 AM, "Eric Sorenson" <[email protected]> >> 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 Developers" group. >>> 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-dev?hl=en. >>> > -- > 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/-/KtqHUAhcelcJ. > 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. -- Daniel Pittman ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
