(I'm kind of rate-limiting my response to this thread; it's long enough that it could take over my life if I let it.)
On Oct 31, 2008, at 10:33 AM, jerico wrote: > [...] >> The goal of a definition is to function as a composite resource, >> allowing multiple Puppet resources to look like a single resource. >> The point behind classes, however, is to delineate all of the >> resources necessary to provide a given service. I often call them >> 'service classes', rather than just 'classes'. > > I think this distinction inherited a lot of cfengine and comes natural > to someone who worked with cfengine for years. I was aware of > cfengine's semantics and grammar when I made my post. I however > believe that cfengine did very much "organically grow" over the years > rather than being "consistent" or "well thought out". Puppet already > does a *good* job in addressing some inconsistencies in cfengine > though! I agree it's somewhat a hold-over from Cfengine, but it's actually more closely tied (at least in function, if not terminology) to my ISconf 3 implementation, which had nodes and types, and each type had a list of work associated with it (ISconf used standard make stanzas for work, so it was all shell scripts). I implemented the same basic idea in Puppet, but instead of a fixed list of resources per class, you get a more powerful language (ISconf just supported attributes or stanza names -- no conditionals or anything crazy like that). Either way, my previous point still stands -- I'd rather us develop a comprehensive view of how this should really work, and then work toward that, rather than just hacking admittedly-imperfect design so it's slightly more usable. In other words, I think the low-cost approach (fixing current stuff) is not the right idea here, and a higher-cost approach (where cost is mostly design) is the right solution. > >> Given this, there are really two questions: >> >> 1) Are these actually two separate purposes? >> 2) Have I chosen syntax that does a good job of meeting each purpose? >> >> I maintain these are two clearly separate purposes. >> >> However, I tend to think that the syntaxes aren't necessarily that >> great, and I definitely agree that we need more functionality for >> configurating classes while at the same time the functionality we >> have >> is a bit not-so-great. > > If classes gained the ability to declare "instantiation parameters" so > that encapsulation and information hiding can be enforced with classes > then my main objection to classes would vanish and I as a user would > be completely happy with that, even if you maintained the semantical > distinction between classes and definitions. This would obviously be straightforward, at this point, in that one could just use the existing definition syntax for adding parameters, although it would further confuse the distinction between them. I'm amenable to this change as a short-term mechanism for adding attributes to classes, but I would tend to require a change with it: The '$class::attribute' syntax would only be able to see the attributes mentioned in the prototype, rather than any internal variables. I still think a long-term vision needs to be clarified, though. > > Btw: Now that I worked a little more with puppet I see the same > problem with templates. They don't declare the parameters they use. > IMO that's a not-so-good idea. But this is somehow less important in > practice as templates are a lot more "local" than classes are. Exactly -- templates are inherently local, and really, there's no way that I know of you could do them any other way. Not unless you wanted to invent your own templating system, which I think is a real mistake. > > I also agree with you that public class variables (or potentially > public attributes of definitions) are not really necessary although I > do not consider them "evil". IMO they serve the purpose of providing > self-documenting parameters to other services (e.g. being able to use > ssh::port in a firewall rule is nice) without breaking encapsulation. > They also help to explicitly identify and declare dependencies between > services (i.e. "automatic require relationships"). And as "definition > attributes" they would provide a nice way of accessing internal read- > only parameters (e.g. "package::platform") which is not possible today > AFAIK. If public class/definition attributes were missing, however, I > could well do without them. You'd retain all of this; you just wouldn't have it to *all* variables, just those that are mentioned in the prototype. > > You also said that deprecating syntax constructs is not "backwards > compatibility" and you are right with that! I admit that my "backwards > compatibility" was rather superficial or simply wrong. Adding > "instantiation parameters" to classes and public attributes to > definitions would however be fully backwards compatible I think. I > withdraw the rest of my proposal. > > So overall that's already it. If you are short of time then you can > stop reading here and you got all the most important. I think we now > mainly agree on which improvements could be made if someone found the > time and priority to do it. Great. I'll respond to the rest of your email in a different email, with a new thread heading. Hopefully we can keep this thread trim, while the other spirals into theory and star-gazing. :) -- The great tragedy of Science - the slaying of a beautiful hypothesis by an ugly fact. --Thomas H. Huxley --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
