On Tuesday, May 7, 2013 11:05:55 AM UTC-5, Ken Coar wrote: > > On Tuesday, May 7, 2013 10:25:05 AM UTC-4, jcbollinger wrote: > > If class 'mod' is going to declare any other classes of the module, then >> those particular classes cannot follow your "all other classes" pattern. >> > > I don't do any class-defines-other-classes stuff. I prefer (because I > understand and hence am more comfortable with) one class *per* file. >
I commend you on that approach, but it's not what I was talking about. To "declare" a class is to use the 'include' function, the 'require' function, or a paramterized-style class declaration to assign it to the target node. This is something you say class 'mod' may do in a single-function module, but you cannot rely on it to work correctly if the declared (included) class follows your "all other classes" pattern. > > >> Class mod::base is confusingly named. It undoubtedly makes sense to you, >> but to me it strongly suggests a base class for class inheritance. If your >> module structure needs to be easy for anyone other than you to grasp, now >> or in the foreseeable future, then I recommend choosing a different name. >> > > Good point. > > Or possibly, just dispense with class mod::base altogether. I'm not sure >> what the "any other things" that it provides for might tend to be, but I'm >> guessing little, if anything. And what there is could be moved to class >> 'mod' without disturbing your scheme, since mod::base includes mod. >> > > Not exactly; other modules might need settings from module mod. > Explicitly including it or letting it be autoloaded will get the settings > without any side-effect actions being taken. > Ok, though that's only relevant to multi-function modules. I do think you may be overengineering this a bit. My gut feeling is that you have at least one class too many in your model framework. > >> That leaves just >> >> - inheriting mod::defaults, which does not help other classes because >> they inherit mod::defaults themselves >> - including class 'mod', which is a possible problem in some modules, >> as discussed above >> - including mod::settings, which is not harmful, but also not useful, >> because parent class mod::defaults also includes mod::settings. >> >> mod::defaults includes mod::settings so that aspects of the resource > defaults can be overridden by values determined by mod::settings. That's > the only reason. > So I guessed. I'm not saying mod:defaults should not include mod::settings, nor either that mod::base should not do so. I am merely saying that that aspect of mod::base does nothing to help other classes that themselves inherit from mod::defaults and include mod::base, according to the pattern you set out. Overall, my point is that mod::base isn't really doing much for you at all. Cheers, 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
