Due to the dynamic scoping of them I only really use them for setting
global defaults. And some mechanism for doing that is really needed.
Using them inside classes is really mostly syntactic sugar to get the code
shorter. But I've also seen them used to conditionally set an attribute. So
not set it to value or undef, to set it to value or not set it at all, as
that has slightly different semantics. But that would also really be better
to do with some sort of postfix if condition in the resource declaration.
On 4 Jul 2014 03:49, "Henrik Lindberg" <henrik.lindb...@cloudsmith.com>
wrote:
> On 2014-03-07 9:40, David Schmitt wrote:
>
>> On 2014-07-02 21:55, John Bollinger wrote:
>>
>> at the point where affected resources
>>> are declared (for Lindberg-style defaults) or at the point where the
>>> defaults themselves are declared (for Schmitt-style defaults, if I
>>> understand that proposal correctly).
>>>
>>
>> My proposal would actually collapse those two points: the values only
>> affect the resources declared in the same resource block as the values
>> themselves. I'll explain my example more:
>>
>>
>> No defaults:
>>
>> file {
>> "/tmp/foo":
>> content => 'foo',
>> mode => 0321,
>> owner => weird;
>>
>> "/tmp/bar":
>> content => 'bar',
>> mode => 0321,
>> owner => weird;
>> }
>>
>> equivalent Schmitt-style shortcutting:
>>
>> file {
>> # defaults block (no title!)
>> mode => 0321,
>> owner => weird;
>>
>> # actual resources block (no mode, owner)
>> "/tmp/foo": content => 'foo';
>> "/tmp/bar": content => 'bar';
>> }
>>
>> simply allowing the keyword default describe the default would do it.
> i.e.
>
> file {
> default:
> mode => '0321',
> owner => weird;
>
> 'tmp/foo':
> content => foo;
>
> 'tmp/bar':
> content => bar;
> }
>
> And, if you wanted a resource with the actual title 'default', you would
> quote it.
>
> (We cannot accept a resource without a title due to how the grammar works
> - long story)
>
> I can also imagine the capability to reference default values via name -
> set elsewhere. It would then be totally up to the designer to configure
> them and use them, and all references would be clear.
> Being able to set them from a hash is also a lot more powerful since the
> content of the hash can be computed much more easily than
> the resource default expressions where you basically have to do any
> computations first and store in a hash or variable, and then construct the
> defaults expression (or some variant with embedded complex logic inside of
> the defaults expression which is even messier).
>
> So, I can imagine syntax like below to reference a set of default values:
>
> e.g.
> $file_defaults = { mode => '0321', owner => weird }
>
> file {
> default: $file_defaults;
>
> 'tmp/foo':
> content => foo;
>
> 'tmp/bar':
> content => bar;
> }
>
>
> I can only remember *seeing* Defaults in modules when they leaked to
>> somewhere I didn't want them to. That's probably the root cause for my
>> idea of really restricting where the default values can go.
>>
>>
> I like the idea of exactly, and explicitly defining what the defaults are
> - no surprises. And, it is up to the designer of a module to expose
> any wanted variability which is now precise. You can have multiple
> (conflicting) sets of defaults that apply to different groups of resources
> in the same context etc. (this is impossible today).
>
> If we do this, then we can drop the current resource defaults expression
> completely!
>
> Schmitt-style ftw !!
>
> - henrik
> --
>
> 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/lp5163%2472b%241%40ger.gmane.org.
> For more options, visit https://groups.google.com/d/optout.
>
--
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/CAAAzDLdiHZ4-TR5pAN0kJSrXw62cbgDm649zkZx5BBGuD_Z0Xw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
