On Wed, Aug 6, 2014 at 1:30 PM, Henrik Lindberg <
[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,
}
}
>> 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 [email protected].
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.
