I'd like to say I really like the intent behind this. Yes, a name is important. So is continuity. I believe the underlying goal is to provide a collection of reference material. Once the skeleton of this material is generally agreed upon, it can be used as guidelines to the community for how to implement a common set of functionality with performance, and the greatest quantity of interoperability in mind.
How is this a bad thing? The demonstrated example shows plenty of well thought out functionality. How might we better implement these functional knobs and levers? Lets go beyond the fact that the only reason we call knobs, switches, and levers what we do is that communally we agreed that this long-ish thing protruding from this surface over here should be called a lever, that this definitive state toggle be called a switch, and this round, grabbable twisty thing here should be called a knob. Names are important, but not just because they're names, they're icons of functionality. Consistently referring to a lever as a lever provides more intuitive context, but doesn't change how it operates. Does it do the same thing if you call it a widget? Sure! Does it help with the goal of communally establishing conventions of grounding and interoperability? Not so much. So, on the one hand, no, this conversation is not purely about naming conventions. On the other, I don't think that's the point to focus on. I can absolutely see the value in a few sets of versioned "interoperability reference" modules, which provide one a good working model of how to provide specific bits of functionality in as flexible a manner as necessary. There are several different good module paradigms out there. I feel that fragmentation of design and implementation hinders the community more than a little bit. It confuses it, at the very least. I do not believe a 'one-size-fits-all' paradigm would do us all that much good here either. You'd likely always be one side or the other of too much scaffolding for simple modules, and not enough flexibility for complicated ones. I believe this means a few levels of module complexity would need to be modeled. Then the transitions between those states would be more straightforward. Someone could expand the functionality of your module with greater ease and consistency. I would love to see other examples which provide similar levels of implemented functionality. (... (:(: and then the bikeshedding and performance holy wars can really get going :):) ...) What other good ways are there to easily write unit tests to validate the different behaviors of a module without parameters? Facts? Limited scope/functionality subclasses? This is a very exciting subject of conversation. I am thankful to everyone participating in it for their thoughts and contributions. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
