> > > > 1) I really don't want to see variable expansion in expressions that >> resolve to the names of types. This will be misused, it will make code >> unreadable. Please leave it out. Sets of parameters only make sense to >> distinct types anyways, if two types really do accept all the same >> parameters, then the RAL should be leveraged and different providers >> written. >> > > It is already used (via create_resources), and people want it to support > integration use cases between more tightly coupled modules. >
The fact that only four modules use it is, to me, exactly validation that > it’s a rare enough use case that it should be left to things like functions. > > The language should be optimized for the most common use cases, not the > complete list of them. > I think Luke has nailed it. Only in the rarest circumstances will this be used to make the code better, and thats not something that should be optimized for. > > What do you think about the proposal to precede the "meta parameter" name > with @, since we have issues with reserving yet another name (all good > names seems to be in use somewhere already). > > We proposed @attributes, so by analogy, it would be @params_hash, or > equivalent using the word you preferred. > I think my disagreement on this is that I consider adding @something to the type syntax to be a bigger crime than reserving a word. If it ends up googleale, I'm okay with it. > (you probably wanted $params = $defaults + $attributes) > Yes, I did. Thanks for taking the time to figure out what I meant, because what I said was garbage. Is $hash1 + $hash2 something that works? I would expect merge behavior there, is that what happens? Thanks, Spencer On Tue, Aug 12, 2014 at 11:48 AM, Luke Kanies <l...@puppetlabs.com> wrote: > On Aug 12, 2014, at 10:02 AM, Andy Parker <a...@puppetlabs.com> wrote: > > On Mon, Aug 11, 2014 at 8:54 PM, Spencer Krum <krum.spen...@gmail.com> > wrote: > >> 1) I really don't want to see variable expansion in expressions that >> resolve to the names of types. This will be misused, it will make code >> unreadable. Please leave it out. Sets of parameters only make sense to >> distinct types anyways, if two types really do accept all the same >> parameters, then the RAL should be leveraged and different providers >> written. >> >> > I hadn't looked for this information before because I just assumed that if > it is possible it is being used :) However, I just did a quick trawl > through the forge and the following modules use variables for the type in > create_resources: > > * vstone-apache > * puppetlabs-swift > * jaydub-resource_factory > * eNovance-cloud > > There is also jakeb-system and erwbgy-system which seem to be copies of > one another. They don't use create_resources, but seem to have forked it > into a new function called system_create_resources which is then used with > a variable type. It isn't clear to me what is different about the forked > function. > > Looking at the examples, usage of interpolating the type name is usually > done in order to have different defined types for different situations, but > shield the user of the module from needing to know about them. This seems > like a very reasonable use. > > > The fact that only four modules use it is, to me, exactly validation that > it’s a rare enough use case that it should be left to things like functions. > > The language should be optimized for the most common use cases, not the > complete list of them. > > […] > > -- > http://puppetlabs.com/ | http://about.me/lak | @puppetmasterd > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/BAF188D7-BF00-49AD-8F54-7E5FC4F971ED%40puppetlabs.com > <https://groups.google.com/d/msgid/puppet-dev/BAF188D7-BF00-49AD-8F54-7E5FC4F971ED%40puppetlabs.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Spencer Krum (619)-980-7820 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CADt6FWMj_2cdSB-%3DywMHU6vT8m%3DXNF%2BAX8-wXnc2iQJtdx9hZQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
