On Wednesday, April 30, 2014 9:23:49 AM UTC-5, Alex Scoble wrote: > > Hi John, > > Thanks for the info. > > By the way, I started using the inherit pattern with params because of the > myriad of Splunk modules out there that do it, including this one from > Puppet Labs https://github.com/puppetlabs/puppetlabs-splunk >
Where that PL module uses class inheritance, it is for one or both of the two reasons I gave earlier. Some of the classes inherit class splunk::params in order to use variables of that class as default values in their own parameter lists. Inheriting splunk::params ensures that that class has already been evaluated when the child class is evaluated. Where the child classes in fact refer to variables from splunk::params, they do so via their qualified names. The classes in the 'platform' subpackage inherit splunk::virtual. They do so in order to override parameters of resources declared by splunk::virtual. As far as I can tell, they do not refer to any of splunk::virtual's class variables via unqualifed names. So actually, that module provides a pretty good example and model of several of my above points about class inheritance. It does have a few flaws, though -- most notably, it parameterizes class splunk::params that is intended to be inherited. Notwithstanding my practical arguments, the language reference explicitly forbids inheriting from parameterized classes<http://docs.puppetlabs.com/puppet/3/reference/lang_classes.html#inheritance>, so the PL crew really should know better. > > I understand why the pattern is used, it makes it a bit easier to deal > with variables, particularly with hiera. > If that's what you're gleaning from the PL module then no, it seems that you don't understand why the pattern is used (there). > I also understand what you are saying. This is the sort of thing that can > drive one nuts, heh. It would be nice if there was only one way to do > things and the one way was also the right way, but such nirvana is hard to > find. > > I do not claim to be keeper of the One True Way, but I am fairly well informed about this community's current opinions about best practices for Puppet manifest code (and at times I have disagreed with aspects of them). You will certainly code things as you think most appropriate, but you should make the best-informed decisions you can about how that actually is. Myself, I am not much swayed by the "Somebody else is doing it" rationale. 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/c7094feb-af21-4afd-9f14-a4df10c87636%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.