Hi Lorenz, > I've commented on that before but i might revise my statement. I use > classes almost exclusively for grouping together defines and therefore > i'm not very concerned about class-level parameters.
As you I am using classes nearly exclusively to bundle definitions. I currently impose a very strict installation hierarchy "by convention" anyway. So "above"/"below" comes naturally to me. Therefore I like your idea of "above" and "below" as it solves some of my problems as well although I unfortunately do not find the time to fix the code as you did. Thanks for your contribution! I'll try it out later. My current workaround is: I am using a custom "installed" parameter with my definitions to emulate the behaviour you are providing through "above"/"below". Then I use a couple of "if" statements within my definitions that ensure that enable, ensure, require, before, notify and subscribe get fixed depending on installed=false or installed=true. Like that I can uninstall resources as a bundle and in the right order without causing damage. I leave them in "uninstalled" state until all nodes have updated their state then I can remove the definition instances from the configuration. I prefer this approach over class inheritance (enable/disable): 1) Above all: I don't like classes at all for state management as they do not accept parameters and force me to use global variables (which I won't, see links below) 2) The installed-variable can be easily passed on to nested lower- level definitions. If you use class inheritance however you usually have to fix more than just one variable when you want to flip state from installed to uninstalled or vice versa. 3) And of course I generally don't like the concept to "hard code" state into class names as it's more difficult to maintain when you extend or refactor your classes/definitions. It's obvious that I'd prefer a "native" solution to the problem rather than having to work around it with all the practical problems implied. > I somehow worked > around them. On the other hand i see that there are some use cases for > parametrized classes but i just would think about them as singleton > defines - which is what they actually are in reality. I also agree with you that there is no real conceptual difference between classes and defines. This was not such a problem if they were really syntactically equivalent. But that's not the case. Classes don't accept parameters and therefore invite use of global variables which I believe is a very bad idea. Definitions are not inheritable and do not provide namescoped variables (or better: constants). See this post for a rather complete discussion of the conceptual similarities/differences between classes and defines (and scope for improvement) that I had with Luke: http://groups.google.com/group/puppet-dev/browse_thread/thread/5e211ec60186c077?hl=en# This discussion is based on the following earlier post http://groups.google.com/group/puppet-dev/browse_thread/thread/23d5e56f1770ec85?hl=en# and on my feature request #1645 @Luke: I am linking this so that you don't have to repeat your arguments again. Florian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
