On 2014-06-08 19:29, Wil Cooley wrote:
On Aug 5, 2014 6:41 PM, "Reid Vandewiele" <[email protected]
<mailto:[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, ... }

I assume you mean {ssl => true, ...}, and not the value of a variable $ssl ?

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




And:

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

Both of these results in an error, you are not allowed to set ssl twice (most likely a mistake).


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.

undef only has a special meaning when it is the final value of the given attribute; it then means "No value specified for this parameter".
That is undef behaves as a "value" until the resource creation takes place.

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.

Yes, that is the way to go. In feature parser it is also very easy to create a new hash where one or several keys are removed. Like this:

  $a = { a=> 10, b => 20, c => 30}
  $b = $a - [a, b]  # $b is set to {c => 30 }

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
    }


So, that was the initial proposal '*' for any name followed by => and the value. This also looks similar to the unary splat '*' that can be used to unfold an array or hash.

That suggestion was not well liked... "no more operators please...".

It would be possible to specify '*' as signaling "here is an attributes hash". The only quirk is that it would be a special syntactic marker that is followed by any expression (which includes splat) - no harm, just slightly odd that you are allowed to write **$extra_opts, where this is not allowed elsewhere (splat is non associative, just like unary minus).

- henrik

--
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]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CAMmm3r557mJAxXT0m3vXv6T9OMfQCwK9npkdnT7Ro7ttkGtgUA%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-dev/CAMmm3r557mJAxXT0m3vXv6T9OMfQCwK9npkdnT7Ro7ttkGtgUA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.


--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
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/lru394%24fdg%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Reply via email to