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 [email protected]. 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.
