----- Original Message ----- > > Does it serve the users that we are recommending they use such a > feature? > > I think the net gain is worth recommending parametrized classes. > > The net gain I see is that it helps new and veteran Puppet users > flatten their nested scopes and avoid unintended side effects which > arise from variables referenced but not defined in the local scope and > resource defaults. > > In the example you posted previously, what scope does class apache > exist in? You included the class twice, once in the top scope and once > inside of class apache::php. > > The class is only included once so it's either top or inside of > apache::php. It's unclear reading the code what the resulting scope > and behavior of the apache class will end up as.
This is due to the strange design of scoping in puppet not due to the desire of wanting to look at code and know what it depends on. when you look at the apache::php class - perhaps in a emailed diff from your SCM you know what it does, it needs apache class. This is a valid wish and today with the state of param classes that relationship isnt going to be clear. > > > > Do we not almost guarantee costly from a time and effort and risk > basis > that using this feature will result in a very difficult migration to a > future > version of puppet? > > > I don't think we guarantee a difficult migration if we recommend > switching to parametrized classes. On the contrary, I think we all > agree we _must_ address the scoping issue at some point. I've > previously [1] recommended we change the behavior of include to always > add classes at top scope, but didn't get much positive feedback from > this idea. > > If we must address the scoping issue, there is a significant chance > the migration to the fix will require non-zero effort. My educated > guess is that migrations will be far easier if the code base is > already using class parameters and you have a guarantee multiple > inclusions aren't happening in the puppet manifests. the specific php example here is bike shedding and I dont care for it, the overall point is there are features that are not designed in a way I believe has everyones needs in mind and certainly hasnt had community input. The language design process needs to be improved so that the result is less inconsistent and weird. -- R.I.Pienaar -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
