On Thu, Apr 14, 2011 at 12:24 AM, Felix Frank < felix.fr...@alumni.tu-berlin.de> wrote:
> 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 > +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. > We started having this conversation back in October, but no design decision was ever made. Here are some links to tickets related to how include and param classes working together: http://projects.puppetlabs.com/issues/5046 Perhaps with the pending changes to dynamic scoping its worth revisiting this ticket and seeing how include and param classes can work together. http://projects.puppetlabs.com/issues/5089 http://projects.puppetlabs.com/issues/5074 > 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. > > -- 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.
