Oh, I'm completely happy with the new scoping scheme and have worked around any issues.
I just think that this should be a failure case since it is currently (and probably has always been) something that shouldn't be done but happened to previously work. Trevor On Tue, Jan 3, 2012 at 10:12 AM, jcbollinger <[email protected]> wrote: > > > On Dec 26 2011, 7:56 am, Trevor Vaughan <[email protected]> > wrote: >> I just ran into an interesting scenario where I didn't know how to >> scope my variables and I'd just like to share for the crowd. >> >> Suppose you have two modules 'foo' and 'bar'. You also have two >> defines, 'foo::do_stuff' and 'bar::more_stuff'. >> >> define foo::do_stuff ( >> $var1 = 'a', >> $var2 = 'b' >> ) { >> bar::more_stuff { 'test': } >> >> } >> >> define bar::more_stuff ( >> $optional_var = 'ignore' >> ) { >> file { '/tmp/test': >> content => template('bar/random.erb') >> >> } >> >> +++ random.erb +++ >> >> var1 = <%= var1 %> >> var2 = <%= var2 %> >> >> So, here, puppet complains about the scope of var1 and var2 but what >> should the correct scope be? foo::do_stuff::var1, etc...? But how does >> that work with multiple define calls to foo::do_stuff? >> >> This, of course, can be avoided by putting the template under >> foo/templates and forcing the passage of content to bar::more_stuff >> but I'm not quite sure *why* this isn't supposed to work and what to >> do about it with the notice that 2.8 will force the scoping of all >> variables. > > > Definitions are not equivalent to macros. Among other things, the > variables a definition declares are not added to the scope from which > it is instantiated, which is to say that definition instances > establish their own variable scopes. > > Templates resolve variables from the scope in which the template() > function is called. The var1 and var2 are not local to that scope in > your example (see above), and that's why you get a scope warning. > > Or did you mean you don't understand why dynamic scoping is being > removed? The basic reason seems to be that those making such > decisions judged that it causes more problems than it solves, and that > there was nothing that could be done with dynamic scoping that could > not also be done by other means. Indeed, I am convinced that a > significant reason for the introduction of parameterized classes was > to make that so. > > As for you current case, I think the best solution is indeed to add > var1 and var2 as parameters to bar::more_stuff. They are de facto > parameters anyway, by virtue of the template's (dynamic) use of them, > so putting them in the parameter list makes things clearer (and thus > more maintainable). It also gives you more freedom in how you use the > definition. In other words, there is plenty of upside. > > > John > > > >> >> Thanks, >> >> Trevor >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 >> [email protected] >> >> -- This account not approved for unencrypted proprietary information -- > > -- > 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. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- 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.
