On Tuesday, May 7, 2013 10:25:05 AM UTC-4, jcbollinger wrote: > > I think there's a great advantage to using a consistent module structure, > whatever that happens to be.
D'accord! Hence this attempt. > >> >> 1. mod::defaults (defaults.pp) >> - does *not* inherit from anywhere >> - 'include mod::settings' >> - references module variables with $mod::settings::varname >> 2. mod::base (base.pp) >> - 'inherits mod::defaults' >> - 'include mod' >> - 'include mod::settings' >> - any other things which apply to all classes in the module >> 3. mod::settings (settings.pp) >> - does *not* inherit from anywhere >> - has responsibility for resolving and normalising any global or >> mod() class variables into sane values >> 4. mod (init.pp) >> - 'inherits mod::defaults' >> - 'include mod::settings' >> - imports all $mod::settings::<varname> definitions into the $mod >> namespace >> - if it's a multi-function module (*i.e.*, classes may be >> selectively called out for use), this is all it does. >> - if it's a single-purpose module, the rest of its work can go >> here -- or in other classes it includes >> 5. all other classes >> 1. 'inherits mod::defaults' >> 2. 'include mod::base' >> 3. does whatever else it's suppposed to do. >> >> The ideas I'm working from are to abstract all the parameter selectors >> and such into one class, >> > > > Not to be dense, but that class is mod::settings? > Correct. resource declaration defaults into another, >> > > And that one is mod::defaults? > Correct. and the module top-level namespace and every-class-needs-this stuff into a >> third. >> > > And mod::base? Or is this mod? > A combination. The namespacing is both (since mod::base includes mod), and the 'common stuff' is mod::base. > That resource defaults are so important to you that you make special > provision for them in your standard module structure seems a bit > questionable to me. > I understand. However, there are some significantly involved resource declarations that only change a few parameters (if any) in other classes -- but to retain the defaults means using 'inherits'. (I first started messing about with 'inherits' to get the variables from mod::settings imported into the top -- and each class local -- namespace, but I was shown some problems there. > Which, if any, of these classes are parameterized? Not mod::defaults, I > presume, because parameterized base classes are not supported (though they > don't automatically fail). Are any of the others allowed to be > parameterized? This makes a great difference to the analysis. > In the current iteration, only mod might be parameterised -- and it usually isn't. Hence all sorts of selectors in mod::settings to derive operating values from the global scope (node manifest, facts), defaults, and possibly parameters to mod if they're supported. Moving from global parameters in the node manifests to parameterised classes is in the plan. 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. > 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. > 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. > I think it might help to re-cast your pattern categories. In particular, > "all other classes" is probably too broad a category, and class 'mod' may > not deserve to be in a category by itself. It might be to your advantage > to draw the line between outward-facing classes and other classes, instead. > Thanks, I'll ruminate on that. -- 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.
