Issue #22584 has been reported by Chris Wilson. ---------------------------------------- Feature #22584: Loss of dynamic scope makes classes MUCH less useful https://projects.puppetlabs.com/issues/22584
* Author: Chris Wilson * Status: Unreviewed * Priority: Normal * Assignee: * Category: class inheritance * Target version: * Affected Puppet version: * Keywords: * Branch: ---------------------------------------- For example, we have some classes: * ldap::common * ldap::client extends ldap::common * ldap::server extends ldap::common * ldap::mirror extends ldap::server ldap::server defines a slapd.conf file using a template. ldap::mirror needs to modify the contents of that template. The easiest way is to set a variable in ldap::mirror: <pre> $ldap_type = "mirror" </pre> and switch on that in the template: <pre> <% if ldap_type == "mirror" %> syncrepl rid=<%= ldap_rid %> </pre> Unfortunately that doesn't work. The template never sees $ldap_type because it's generated in ldap::server, and ldap::server's scope doesn't include ldap::mirror, a subclass (as far as I can tell). This is just losing ALL the power and expectations of inheritance. In what OOP programming language can you not override the values of member variables in a subclass? The only ways I can think of to introduce this behaviour right now are: * Parameterise ldap::server. But whether it's a mirror or not is not really a parameter! It's something I want to override in a subclass. In theory I might want to override *anything* in a subclass. And I don't want to have to introduce hundreds of parameters onto my classes and set them appropriately everywhere I need them. * Override the resource definition of the template that uses $ldap_mirror in ldap::mirror, replacing it with an identical copy. Not DRY. * Extract that resource definition into a separate class and include it from both ldap::server and ldap::mirror, after defining $ldap_mirror. But a possible solution occurred to me that would preserve the power and expectations of OOP: the scope used when interpreting an inherited resource should be the subclass, not the class where it was defined. Does that make sense? Is it hard to implement? -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
