FAQ

On Fri, Sep 14, 2012 at 11:31:08AM -0700, 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: [..]>
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. [...]
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.sorenson@puppetlabs.com
PuppetConf'12 - 27-28 Sep in SF - http://bit.ly/pcsig12
I use this a lot to be able to have an optional parameter in a parent
class that is passed to an included class and the included class
determines the default value. Like:

class basic($puppet_cron = undef) {
class { 'puppet::client':
cron => $puppet_cron,
}
}

-Stefan

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Search Discussions

  • Jcbollinger at Sep 17, 2012 at 2:31 pm
    I expect param => undef to be an explicit expression of 'param' not being
    specified by the current declaration, or as an override, to express the
    idea of the overridden resource as if 'param' had not been specified. The
    latter is essential. The former follows for consistency, because

    foobar { 'example':
    param => undef
    }

    should not express a different resource state than does

    Foobar['example'] {
    param => undef
    }

    Moreover, my gut feeling is that having the undef bind to the actual
    parameter instead of being declaration metasyntax implies a need for users
    to have more knowledge of the details of the definition's (or class's)
    implementation than is reasonable. Though users may indeed have such
    information in some cases, that still doesn't sit well with me.


    John

    --
    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/-/F0rGcYv_GAQJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedSep 14, '12 at 10:36p
activeSep 17, '12 at 2:31p
posts2
users2
websitepuppetlabs.com

2 users in discussion

Stefan Schulte: 1 post Jcbollinger: 1 post

People

Translate

site design / logo © 2021 Grokbase