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';
   }

the weird owner and mode do not apply to any resources outside of this File declaration. The resulting resource would not remember whether the parameter value was set directly (content in the example) or with a shortcut (mode, owner).

Any way around, I think there will be a major upheaval when the scope of resource defaults changes. Would it at least be possible for their scope to continue to extend into defined type instances declared within their lexical scope? That would mitigate the problems a bit, without causing any unpredictable evaluation-order dependencies. That would also be consistent with how the metaparameters of a defined-type instance are forwarded to the resources it contains. The semantics of wrapper definitions will otherwise
change significantly, yet subtly.

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.


Regards, David

--
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/8955769e2a9cd58dfda550454d3a9337%40hosting.edv-bus.at.
For more options, visit https://groups.google.com/d/optout.

Reply via email to