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.
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"
> <eric.s...@puppetlabs.com<javascript:>>
> 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 - eric.s...@puppetlabs.com <javascript:>
>> 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 puppe...@googlegroups.com<javascript:>
>> .
>> To unsubscribe from this group, send email to
>> puppet-dev+...@googlegroups.com <javascript:>.
>> 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 puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
