On Tue, 12 Oct 2010 15:51:29 -0700, Paul Berry <[email protected]> wrote: > On Tue, Oct 12, 2010 at 3:41 PM, Luke Kanies <[email protected]> wrote: > >> On Oct 12, 2010, at 2:22 PM, Nigel Kersten wrote: >> >> > On Tue, Oct 12, 2010 at 2:17 PM, Markus Roberts <[email protected]> >> wrote: >> >> >> >>>> Hmm, the number of people chiming in on this topic is making me >> >>>> wonder >> >>>> whether we are barking up the wrong tree with lexical scoping. If >> people >> >>>> don't need for variables and resource defaults defined in a class to >> take >> >>>> effect in contained classes, then there's no sense in our going to >> extra >> >>>> work to support it. >> >>>> >> >>> >> >>> Can we drop both lexical and dynamic scoping and still keep this >> property: >> >>> >> >>>>>> 1. Variables defined at toplevel can be seen inside classes. For >> >>>>>> example: >> >>>>>> $var = "value" >> >>>>>> class foo { notify { $var: } } >> >>>>>> include foo >> >>>>>> >> >>>> This is a good idea and should stay, short and long term. >> >> >> >> Q: Can we drop both lexical and dynamic scoping and still keep the >> property >> >> "Variables defined at toplevel can be seen inside classes"? >> >> >> >> A: Yes. Globals don't require scoping. :P >> > >> > Do we need scoping for inherited classes to inherit resource defaults >> > and variables? >> >> Yes, but would it be acceptable to remove that and rely on the mixin-like >> behaviour I mentioned earlier instead? >> > > I think the discussion is boiling down to four fundamental questions that > we're achieving consensus on. Let me try to state what I think those > questions are, and the consensus I'm hearing: > > (a) Do we want to remove dynamic scoping from Puppet (variables and > resource > defaults defined in class A also take effect in classes that A includes)? > Yes. But we should remove it carefully and with appropriate warnings, so > that users have time to adapt their manifests to use parameterized classes > etc. And we may need to add Luke's proposed "extend" concept to address > some of the use cases of resource defaults. (Personally, I think we have > enough of a consensus that we could move forward with this, and consider > the > "extend" concept something to be elaborated during the timeframe of 2.7 > development.) > > (b) Do we want to add lexical scoping to Puppet (variables and resource > defaults defined in class A also take effect in classes nested inside class > A, e.g. A::B)? No. I thought we did when we began this discussion, but I > think this was because I initially misunderstood the decision as "lexical > scoping or dynamic scoping?" What I'm hearing today is that we don't need > either of them. > > (c) Do we want to remove inherited scoping from Puppet (variables and > resource defaults defined in class A also take effect in classes derived > from A)? No. This is a useful feature and should be kept. > > (d) Do we want to remove globals from Puppet (variables and resource > defaults defined at toplevel also take effect inside classes)? No. This > is a useful feature and should be kept.
Paul, thanks for summarizing the complex discussion so succinctly. I believe these changes will make a solid improvement in reducing the number of surprises (i.e. land mines) hidden in manifests. Something I'm missing here is the proposal whether to remove nesting classes alltogether. I feel that this should be a concequence of agreeing on (b), by way of avoiding a anti-scoping language construct. Regarding the mixin/extend functionality, there is two precedents: the "search"[1] function and inheritance. A "defaults_from" (I suck at naming ;) function that would not only modify the search path but also fetch resource defaults would fit right in the between those two. Having started down this path, I start wondering whether there are common corner cases of these functionalities and which pieces are missing. (1) levels of inclusion are "variables" (search), "resource defaults" (mixin), ["resources for application" (include),] and "resources for overriding" (inherit) (2) collision handling: search: order of search(?), mixin: ??, include: collisions are errors, inherit: can only be used once (3) transitivity: search: no, mixin: ??, include: yes, inherit: yes(?) Best Regards, David [1] http://docs.puppetlabs.com/references/stable/function.html#search -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en.
