On Wednesday, June 19, 2013 5:34:58 PM UTC-5, Alessandro Franceschi wrote: > > > > On Wednesday, June 19, 2013 5:03:41 PM UTC+2, jcbollinger wrote: >> >> >> Call me "experienced", "jaded", or even "cynical", but I know of too many >> instances of vaporware to be swayed by promises of software that hasn't yet >> been written. >> > > I just call you cynical. We can't do anything if we don't try to do it. > >
By all means, do. If you are somehow getting the impression that I object to the project then I apologize. Indeed, I encourage you to proceed, and I wish you well. I just have low regard for software that doesn't yet exist. I do not find the potential for nebulous future software a persuasive argument for adopting anything. What I actually object to is misrepresentation -- even though accidental -- of the nature and scope of the project. It is NOT restricted to choosing names. Secondarily, I object to positioning the effort as a standardization project, and I advise you to position it differently. Names and labels are meaningful. How the project proceeds, who participates, what they propose, and all manner of intangibles will be influenced by your decisions in this regard. Frankly, I am inclined to resist a "standardization" effort from any random third party, but I have no reason whatever to oppose anyone drafting a set of conventions or best practices. After they have been tested in the field will be a suitable time to consider standardization or endorsement. > *A really reusable module HAS to be parametrized*. > Utter hogwash. > Take note, I can repeat and argument that anytime. > Then no doubt we'll be hearing from each other on this again. > Parameters are the API of a module, the interface you can interact with it > without touching it. > If you don't use parameters either you are forcing inside the module > behaviours that can't be changed by users or you are forcing a specific way > to obtain the data that affects the modules behaviour and this inherently > makes it not reusable for people who provide data in other ways. > The data consumed by a module and the labels by which they are identified are certainly parts of a module's API, but it is by no means necessary to express those or interact with them in the form of class parameters. You cannot safely use parameterized-style class declarations (as opposed to class *definitions*) of any API class, especially in or with modules intended to be interoperable. That makes parameterization largely moot as far as reusability goes. If people want to parameterize their classes then I have no special reason to object. I do object, however, to the premise that doing so usefully improves reusability or interoperability, and therefore I object to any proposal that expressly calls for classes to be parameterized. As long as we're talking about standards, Hiera is Puppet's de facto standard interface to external data. It is usually expected that proposed standards will build on other, existing standards, whether de facto or formal. I think your proposal would be stronger if it truly did focus on the data that might need to be supported by modules and the names / labels / keys by which they are identified. If you choose a namespace-based system then you can align it to be consistent with class parameterization and automated parameter binding, yet not dependent on those. I know you want more, but you should consider making a separate effort of the rest. > >> >> Most importantly, however, my central objection here is that a proposal >> that purports to be exclusively about naming parameters in fact has any >> implications at all for module organization and style. >> > > Ok, it's not a proposal that purports to be exclusively about naming > parameters: the usage of specific parameters involve patterns that enhance > modules' reusability and interoperability. > The sample module code definitively exposes design patterns with modules > (and it demonstrates that you can follow different patterns to achieve the > same behaviour. > > Reading it again this is not so clear in the first post here, but it's > widely expressed in the linked pages. > So, sorry, now let's move a step further, let's talk, if you want, about > how to make that paper/draft/proposal better. > And if you think that such a thing should not even be discussed, well, ok, > I'll accept that and discuss it with who is interested in it. > > I think it would be better if it actually were narrowed in scope to identifying patterns in the data that modules consume, and choosing naming conventions for those data. Better, and also easier to reach consensus on. Include some comments about namespacing, especially in conjunction with accessing data via Hiera. These issues are separate from and more fundamental than class parameterization or module organization. They will, however, influence anyone who chooses to write modules with parameterized API classes. John -- 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.
