> That's one of many reasons to not do that. Specifically, one should > employ class inheritance only when it involves overriding resource > properties of the parent class.
We have a history of using class inheritence to override variables in template's or add extra functionality the base classes. Both practices can now be abandoned with the use of parameterized classes. Where all you really want is to compose classes (as I infer is the case you describe), you should > instead use the 'include' function, the 'require' function, or a > resource-style class declaration. Exactly where we are going. > If you use class inheritance *only* to override resource properties > (subclass bodies contain nothing but resource overrides) then I think > your subclasses will not suffer from the problem you describe. Hmm, good point, but I really hope we can get away with just parameterized classes instead of overrides. > You will already have recognized that none of this solves your problem > directly. Effective dependency management requires discipline, > planning, documentation, and the occasional large-scale refactoring. > Correct use of class inheritance fits in mostly by shaping the > expectations and practices of manifest developers, rather than by > providing tools to directly control ordering. I hope you nevertheless > find this useful. This sure is usefull, talking helps to understand the problem and the pro's/con's of different solutions. Jos Houtman -- 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.
