----- Original Message ----- > > > > On Mon, Apr 11, 2011 at 9:25 PM, John Warburton < > jwarbur...@gmail.com > wrote: > > > OK, I'll bite > > In the newly published Style Guide ( > http://docs.puppetlabs.com/guides/style_guide.html ), right at the > end it says > > Modules should avoid the use of extlookup() in favor of ENCs or other > alternatives > > > For clarity, this should read: > > in favor of ENCs in combination with parameterized classes > > > > But there is no reason as to why. > > > that is partly my fault. > > <the following is my opinion, and may or may not express the opinions > of PuppetLabs, although I can be pretty persuasive :) > > > Extlookup provided some necessary pre-2.6.x functionality, namely, a > sane way to get around dynamic scoping.
This is not what extlookup is for. Yes it effectively works around the Wacky Scope problems but that is not its reason for existing. It exists primarily to: - allow the data - lets call it the model - to live separate from the code (controller?) and the templates (view?) - it is easy to grasp, easy to train members of a team and with a bit of discipline its trivial to look at a class and know how you can configure it. - It doesnt require any code changes to change the way the data behaves which is great for shared code like those found on the forge. Unlike the layered class approach - To replace almost all case statements - To be an appropriate level of complexity for the average Puppet user. Compare experiences in #puppet with newbies learning extlookup vs the layered classes approach. Yes the layered classes approach is elegant and less hacky but it is by no means understandable by newbies. The last point is the big one, Puppet has always been a language for sysadmins who want to automate their infrastructure. The layered class approach is something that you only get once sat in a class and taught. In this regard Puppet has lost its way. It is not awesome though, there are limits to how you can configure the data the approach it takes isn't flexible enough really but it solves most of the problems it set out to solve. You cant programatically figure out what a class requires like you can with param classes if you dig deep enough. So an alternative was proposed - Puppet Data Language[1] that combines with param classes to address this properly. > > given the option between parameterized class combined with an ENC vs. > extlookup, I choose parameterized classes+ENC. The reason is > readability and encapsulation. > > In order to understand an implementation of Puppet using extlookup, > you have to understand all of your code in its entirety. After all, > any code anywhere in your modulepath could be calling extlookup and > accessing data. (I would be very interested to hear if anyone has a > good pattern for this) > > With param classes, you can build a layered architecture of classes > that pass data to each other through their explicit interfaces. How easy is it to adjust how you layer these classes? How sharable is this set of layered classes with other teams, other business or event entirely unrelated 3rd parties via the forge? How many inheritance related bugs have gone reported but never fixed? How will the often mooted changes to puppets internal scoping affect already written code? How does layered classes sit with modules already on the forge? In my experience all of these are either unknown or very hard to answer, its difficult to explain as a concept and it is not as flexible or readable as extlookup is in the majority of the cases. These are the problems extlookup exist to address, not a scoping solution. Extlookup replaces a case statement, its trivial to understand, its easy to use and easy to configure. I think it's a much more suitable solution for the average puppet user - a sysadmin - than a complex layered almost OO approach that is favored by seasoned programmer. Our user base simply isn't programmers and understanding complex OO concepts is hard and we should do more to make it easier not harder. This is a known problem, and so Puppet Labs have spec'd the PDL[1] to address these problems, without the PDL I do not consider param classes very user friendly at all. The PDL is a *much* more desirable solution than either layered classes or extlookup, why it has gone un-implemented I dont know and why the current suggestion is that layered classes somehow represents an effective alternative to the PDL I do not understand at all - since surely why bother with the PDL at all then? Because a solution to creating easy to share, document and tweak - without changing the code in the module - is needed and that is what extlookup and the PDL aims to provide. It's a real shame that the PDL has fallen off the wagon and not getting any attention since without it people are stuck with either spending months becoming seasoned Puppet coders or just using extlookup. And without the goal of getting a sharable set of modules written by normal community members is still just a pipe dream. Other have been beating the layered classes drum for years, given talks and presentations at it at each Puppet Camp and promoting their use and they are not adopted widely because they are simply too complex and not fit for the average community user. [1] http://projects.puppetlabs.com/issues/6079 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
