On 2014-07-08 1:18, Wil Cooley wrote:
On Wed, Aug 6, 2014 at 1:30 PM, Henrik Lindberg
<[email protected] <mailto:[email protected]>>
wrote:
$extra_opts = { $ssl => true, ... }
I assume you mean {ssl => true, ...}, and not the value of a
variable $ssl ?
Yes, sorry
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).
I think I trimmed too much context; Reid had proffered two behaviors and
I was responding to the first:
Example 1 (assuming behavior whereinmerging is OK, and that
explicit parameter specification takes precedence):
...
Example 2 (assuming that merging is not OK, and that conflicts
will be treated as duplicate parameter specification):
Example 1 can be used to replace/supplement resource defaults; 2 cannot.
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.
I think that amounts to the same thing, but from different sides of the
compiler, so to speak.
Such as ignoring a resource default:
Exec { timeout => 30 }
# Bunch of execs that sometimes take too damn long
exec { '/usr/bin/sleep 60': }
...
# Then another exec that should have the default timeout, but I
don't want
# to hardcode (or even remember) what that is (i.e. pretend the above
# resource default does not exist):
exec { '/usr/bin/ping localhost': timeout => undef }
Or passing options from a defined type to a type declaration:
define filelike($seltype = undef) {
file { '/tmp/foo':
seltype => $seltype,
}
}
Yes that is how undef works when you are passing arguments to parameters.
apache::vhost { $title: **$extra_opts }
or:
apache::vhost { $title: &$extra_opts }
or:
apache::vhost { $title: *$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...".
Part of what is bothersome to me about the "* =>" proposal is that it
looks like
an assignment to a wildcard, which makes my head spin.
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).
Rather than a special construct that only applied for attributes, it
could be a
general unpacking operator, like it is in Ruby and Python. I guess
that's a bigger can of worms.
It is already an unpacking operator nicknamed 'splat', hence what I
wrote above. The problem in the grammar is that there is the need to
have a syntactic marker, it is impossible to allow any expression at
that point.
I echo Reid's sentiments about language complexity and prefer the metavar.
ok, good, that seems to be what most prefer.
Wil
--
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/CAMmm3r5jAUnP0s_rWVqtUqJ4cZjnuCrLLG77XteG0q7rY7W43Q%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-dev/CAMmm3r5jAUnP0s_rWVqtUqJ4cZjnuCrLLG77XteG0q7rY7W43Q%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/lrugeh%24527%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
