On Apr 18, 2012, at 4:27 PM, Jo Rhett wrote: > On Apr 18, 2012, at 4:04 PM, Andrew Parker wrote: >>> On Apr 17, 2012, at 9:00 AM, Andrew Parker wrote: >>>> Has anyone seen something where a manifest used $::var in order to *not* >>>> get the value of $var that is overridden in a node? >>> >>> Uh… I use it extensively. >> >> Ah, interesting. Could you provide some examples of what you use it for? > > Not offhand, sorry, used it a lot at $formeremployer. Building up new stuff > for $currentemployer and have no examples handy. But I really running into > that 'feature' and going OH! and using it to solve a few problems. >
No problem, if you think of some examples, just let me know. :) >> The bad thing (under the new system) is that node is a special citizen that >> gets to have dynamic scoping, but nothing else does. > > No, I don't want dynamic scoping. But I want node-level scoping distinct from > top-level scoping. I don't want them flattened. > >> If node was not its own scope and instead was just part of top scope, then >> the rules for where a variable comes from turns into "in the class, the >> parent(s), or the topscope". >> >> If node is its own scope that is given special dynamic lookup status, then >> your rules are "in the class, the parent(s), whatever node included the >> class". >> >> In both cases there is the additional complication of node inheritance which >> makes it even harder to figure out what value you are actually going to end >> up with. > > Honestly, everything you just described is why puppet is confusing to code. I > find it much easier to be explicit in all of my calls, so that you know. The > worst bit of modifying a puppet class is finding a variable and not knowing > if it's global or local or inherited, and searching around to figure it out. > Or causing a syntax parsing error because a variable name you tried to use is > already defined, and it's not defined in the class you are operating on -- > it's in a completely different file potentially not even checked out by you > at the time. > > If I want a top-level variable, I'll ask for one. If I want a node-level > variable, I'd like to be able to ask for one (which I can't today afaik). I > never want either of them unless I ask for them by name. > >>> In fact, I'd prefer stricter lexical scoping rather than vaguer. I believe >>> that the current situation is what confuses everyone, and that if >>> referencing something out of scope was ALWAYS explicit that would be >>> preferred. I'd also prefer tighter scoping around each node -- I could >>> simplify a lot of code if this worked better, such that I could use node >>> variables within parameterized classes easily, always being set for the >>> node currently being operated on. >> >> Do you mean having no nesting of scopes at all (i.e. everything is local and >> there is no lookup outside of the scope)? That would mean a lot more verbose >> manifests but is a possible option. > > Yes, I do. Or an option to enable that at least. I realize that many people > love a big swash of global variables, so I'm going against the stream. In > fact, I would appear to be going against the grain of ruby itself. But > sometime after your module repository breaks 20k lines of code you really > want to strangle something every time you get a variable collision you never > intended inside what should be a tight a lexical scope. > Yeah, globals usually cause a lot of confusion and modules should probably avoid putting in top scope or relying on what is there. What do you do with inheritance (classes or nodes) wrt variables? Avoid? Using a lot? Have a specific pattern that you follow? >> Could you elaborate on what you mean by tighter scoping around the node? An >> example of what that might look like, perhaps? > > > One thing I'm referring to (which might have changed recently, but was using > 2.6 exclusively at $formerjob) was that if I used parameterized classes I was > unable to access node variables except by passing them in. This wasn't always > possible due to limited return values/limited syntax. This led to us using a > blend of parameterized classes and included classes, and that really was > insanity to manage. I'd like to go to 100% parameterized but that's hard to > do when you can't explicitly reach for node-level variables. > If you are 100% parameterized why do you need to reach for node-level variables? Shouldn't everything be a parameter to the class/define? > I'm not proposing syntax here, I'm showing what I mean. > $var is always local to the current scope > $::toplevelvar is top level var > $node::nodevar > $class::classvar > > Again, that's not a syntax suggestion just showing that I want to be able to > grab for these things individually and distinctly. > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and other > randomness > > > -- > 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. -- 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.
