On 2014-03-14 17:44, Andy Parker wrote:
We also have to decide if any of the relative name-space functionality should remain (i.e. reference to x::y is relative to potentially a series of other name spaces ("dynamic scoping"), or if it is always a global reference when it is qualified.Other than using the search() function (which I'm not sure it even works), do you have an example of this happening? I can't seem to cause it to occur. If it doesn't really exist, then I'm not too concerned about dropping it :). I know that the relative name lookup happens when finding classes (include(b) can refer to a::b), but haven't been able to get it for variables yet. Figured out a case of this happening: 1 class a { 2 include b 3 } 4 5 class a::b { 6 include c 7 notice($c::x) 8 } 9 10 class a::b::c { 11 $x = 1 12 } 13 14 include a Line 7 ends up looking up the class c, which is looked up relative to a::b and so it finds a::b::c and then it performs the $x lookup in that class. A consequence of this, which I think we should get rid of, is that anything visible from a::b::c is able to be looked up in this fashion. So another way of getting the kernel fact from a::b is to use $c::kernel (or in the new fact hash that is introduced in 3.5.0 $c::facts["kernel"]).
Yeah, that's what I was talking about in my other mail. Under certain patterns this can become quite common and quite painful, both in debugging and how the resolution looks like.
Regards, David -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5323696B.1020904%40dasz.at. For more options, visit https://groups.google.com/d/optout.
