> Although I agree that to be reusable, modules need to provide certain types > of levers, knobs, and switches, as appropriate for their scopes, I think the > case is weak for those controls needing to be called by the same names. At > best, naming conventions for such things might improve ease of (re)use for > some people, but the key factor for reusability is not the names of the > controls so much as their presence in the first place. > > I see implications for interoperability only insomuch as one imagines > facilitating one module being a drop-in replacement for another, but (1) > there's a lot more to that than just common naming, so (2) that kind of > interoperability is unlikely to come about except by specific intention > anyway, so in that case shared naming comes out as a project requirement. > To me, that moots any general parameter-naming standard as far as > interoperability goes.
I think being able to use another class in a drop-in way is not the value I see in parameter naming 'recommendations'. I personal see value in the ease of use more than anything, if parameters are similarly named between classes, when you go to use them you don't have to interrupt, double check with the docs what this class/define uses, then modify your parameter name accordingly. Its a reduction in surprise if anything. An example would be the 'package' parameter, versus 'packages' ... if I didn't have to stop and check which one it is for my XYZ class it might save time and mistakes *shrug*. Is that valuable? Alas, I'm more of developer then user these days so I would defer that to our users. As a developer though - I would find it handy to have a guide for common things, I'm a pedant when it comes to naming and if someone already came up with a name for me, I would probably use it, presuming others have thought through any naming consequences. > None of that is a fundamental reason to object to the effort, but I'm not > seeing any promise of significant benefit to motivate me to participate > actively. > > I do have a bona fide objection, however: although the effort is cast at > this point as being aimed exclusively at parameter naming, by implication it > also covers elements of module structure, organization, and style as well, > as the things being named have to exist for the standard to be relevant. I > do understand that the intention is not to make all the standardized > controls mandatory for every module, but for those that a given module does > provide, even the standard's limited reusability and interoperability goals > are not served if those controls are not located where the standard > anticipates (which is for the most part on a single front-end class). I've been pondering this situation as well. I presume in a world where such recommendations become commonly used, the outcome would be surprise at a missing 'recommended' parameter, then a subsequent bug raised on the module due to its lack. This might be considered a positive or negative. If the parameter name was named 'something else' due to a feeling that the 'standard' is not covering a developers needs, then this could be annoying to have that discussion _yet again_. If however the functionality is simply missing - this becomes a BAU patch (like the lint patches we see all the time) and probably a positive feature request. Of course, this all depends on how good the recommendations are. Having looked through the document I think some of them are obvious, and require less debate while other recommendations are less obvious/contentious. > Personally, I would rather see a white paper explaining what kinds of > controls need to be available to facilitate reusability of various kinds of > modules, and, optionally, setting out one or more models of how a module can > provide those controls. Regardless of the nature of the paper's authorship, > this feels like it should be a position paper, not a proposed standard. Fair point, its a difficult document to position precisely. I guess I foresee this as something that should be a part of a guide for writing modules then any hard/fast rule or 'standard'. ken. -- 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. For more options, visit https://groups.google.com/groups/opt_out.
