On Wednesday, April 24, 2013 9:06:02 AM UTC-5, Mike Power wrote: > > I appreciate the reply but I think the thrust of my point is getting > missed. > > Any other solution is far more cryptic, some reader coming and reading the > code will not understand the code nearly as well. >
That's a matter of opinion and style, of course. And surely you over-generalize, even for people who are inclined to prefer the same style you apparently do. You cannot possibly expect anyone to accept that using defined() as you describe is the clearest, easiest to understand (for anyone) solution to every single problem that can be cast in the very general form you presented. Personally, I find usage of defined() to be very obfuscatory. The local meaning is clear enough, but the overall contribution and implication is not clear at all. Under what circumstances will the given resource be already defined? That's especially important if the defined() condition affects more (or different) declarations than just the one resource it tests. And I'm not talking about parse order here; even an easily predictable parse / evaluation order would not solve that -- it's a question of scope. Moreover, there are correctness and maintainability problems. If you have two classes that may or may not both be used on the same node, and both rely on the same resource, then having each one declare that resource under protection of a defined() condition forces you to continually ensure that each declaration of that resource is consistent with the needs of *all* the classes that (may) rely on it. > The fact that puppet has a dimension (parse order) that is so convoluted > that its behavior cannot be understood is not a virtue. It is a very bad > thing. > > No one claimed that the behavior is virtuous. That's all irrelevant, however, if you follow my advice to avoid parse-order dependencies in the first place. That's widely accepted as a best practice. Leading up to Puppet 3, there was even an initiative to remove the defined() function from Puppet, or at least deprecate it, though that didn't ultimately make it into (out of) the product. Puppet has few other areas of parse-order dependency, and most that it does have can be handled very simply. Inasmuch as you conclude that difficulty in predicting Puppet parse order is a serious flaw, I would think you'd agree that parse-order dependencies are better avoided. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" 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-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
