Hi John, On 04/13/2011 05:47 PM, jcbollinger wrote: > Given my position that the good use cases for parameterized classes > are specialized and few, I tend to agree about different uses. That > parameterized and ordinary classes are different concepts appears to > be more a de facto result than a design decision, however. Other > aspects of Puppet tend to obscure such a distinction. Consider: > < snip >
You raise very good points that I won't argue about. > I think often what you might like to do is declare a class's > parameters once, and elsewhere allow other classes to include that > class without redeclaring the parameters. For instance, perhaps you > have a user::virtual class that on some nodes declares virtual LDAP > users, but on other nodes delares the same virtual users as local. > Such a class might provide a parameter by which the User provider can > be specified. Other classes that want to realize users should include > user::virtual, but they don't care which User provider is in play. You get something similar by having some resources in each type of node require (by metaparameter, not by function) the class in question. No, it won't get auto-included with default parameter values, but you do get a meaningful error message. > Now that I came up with that example, I realize that it points to an > improvement that might be doable right away: allow the include > statement to be used with parameterized classes. That could be > achieved by slightly (but backwards-compatibly) changing the semantics > of "include": > > 1) The "include" statement expresses a requirement that the specified > class be included in the resulting catalog, but it says nothing about > the class's parameters. > > 2) If a class is named in at least one "include" statement that is > executed while compiling a catalog, then the effect depends on whether > the named class is "declared" elsewhere in the manifest: > > 2a) If the class is declared, then include statements referencing it > have no additional effect. > > 2b) If the class is not declared, then it is treated as if the class > were declared, without any explicit parameters, at the point where the > first include statement appears. (Fixing the class declaration to the > first include statement is intended to provide backwards > compatibility.) If such a class declares a parameter for which it > does not define a default value, then an error results. +1 ! Thanks for laying out your position so carefully. Speaking for myself, I learned quite a bit from your posting. Nigel: It would be nice to get "the developers'" position on these proposals. Cheers, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
