On Monday, February 2, 2015 at 2:58:51 PM UTC-6, Trevor Vaughan wrote: > > Inline.... > > On Mon, Feb 2, 2015 at 3:24 PM, Garrett Honeycutt < > g...@garretthoneycutt.com <javascript:>> wrote: >
I'd like to vote for putting all validation at the bottom of the file. > > Honestly, we're getting quite heavy in the amount of cruft in the files in > general. > Agreed. > == Section 10.2.7 > > > I tend to order things in resource alphabetical order because then, if I'm > looking for a file resource, it's in the 'F' section. And I still like the > fact that order doesn't matter in Puppet unless I tell it to. Accordingly, > should I happen to break my order accidentally, I really don't want to care. > > Although I do tend to order my resource declarations as described by 10.2.7, I agree that it is not a particularly useful as a style guideline. I use that order because it makes sense to me and helps me find things, not because of the functional implications (that anyway don't always apply), and I don't stick to that order rigorously. I'd argue that a mandate to order resource declarations specifically by relative order of application is counter-productive. It de-emphasizes the importance of using relationships to specify application order, and may sometimes mask bugs arising from failure to declare needed relationships. > > >> == Section 10.6 >> Suggest that while having required parameters for defines is OK, having >> them for classes is not. There should never be required parameters for a >> class. This breaks the ability to `include` a class. >> >> > No, I disagree here. There are (many) times that I *need* you to give me a > parameter, I can't make one up that is magically correct. Moving this to a > define-only state means that we have to start slinging around singleton > defines which is what parameterized classes got us away from. > > I'd rather have my compile break than end up with a system doing something > nonsensical, particularly when the security of the system may be at risk. > I think the middle ground here would be best: the guide should recommend *minimizing* the number of mandatory class parameters. Although I very much favor declaring classes via 'include', I acknowledge Trevor's point, and I observe that mandatory class parameters can be satisfied by automated data binding (i.e. Hiera), so they don't altogether *break* the ability to 'include' such a class, they just limit it. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5649c5c9-7ce3-4467-874b-ce2c55f3ad5c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
