On Aug 5, 2014 6:41 PM, "Reid Vandewiele" <[email protected]> wrote:

> Example 1 (assuming behavior whereinmerging is OK, and that explicit
parameter specification takes precedence):
>
> apache::vhost { $servername:
>   port => $port,
>   ssl  => $ssl,
>   attribute_defaults => $extra_opts,
> }

Assuming that the semantics of 'undef' haven't changed to preclude this (I
know there are changes coming but don't quite remember what they are), an
interesting couple of cases are:

$extra_opts = { $ssl => true, ... }
apache::vhost { ...
  ssl => undef,
  attributes => $extra_opts,
}


And:

$extra_opts = { $ssl => undef, ... }
apache::vhost { ...
  ssl => true,
  attributes => $extra_opts,
}


My expectation is that in both cases 'undef' means "pretend I've said
nothing about thus attribute here" and that *true* wins in either case.

But what if what is intended is to explicitly *ignore* the setting in
$extra_opts, so that the type's default is used, as if the attribute had
been mentioned by neither the $extra_opts hash or the apache::vhost
declaration? I guess using a hash operation to copy and filter $extra_opts
would do it.

By the way (since the paint's not dry) I think just *attributes* as the
afforementioned metaparam would be best -- it clearly says what it is, is
short, and is meta-sounding enough that I would not even consider using it
"in the field" -- when developing a class, defined type, type/provider, etc.

Another alternative that occurs to me that breaks the "key => val" layout
and so is cognitively distinct is to use something like the facilities that
many modern languages have for passing hashes or arrays as arguments to
methods/functions:

apache::vhost { $title:
  ...
  **$extra_opts
}


or:

apache::vhost { $title:
   ...
   &$extra_opts
}


or:

apache::vhost { $tilte:
   ...
   *$extra_opts
}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAMmm3r557mJAxXT0m3vXv6T9OMfQCwK9npkdnT7Ro7ttkGtgUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to