On 2014-07-08 1:18, Wil Cooley wrote:
On Wed, Aug 6, 2014 at 1:30 PM, Henrik Lindberg
<henrik.lindb...@cloudsmith.com <mailto:henrik.lindb...@cloudsmith.com>>
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 puppet-dev+unsubscr...@googlegroups.com
<mailto:puppet-dev+unsubscr...@googlegroups.com>.
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 puppet-dev+unsubscr...@googlegroups.com.
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.
