On Wed, Aug 6, 2014 at 1:30 PM, Henrik Lindberg <
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,
}
}
>> 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.
I echo Reid's sentiments about language complexity and prefer the metavar.
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CAMmm3r5jAUnP0s_rWVqtUqJ4cZjnuCrLLG77XteG0q7rY7W43Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
