> > > > 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 <[email protected]> wrote: > On Aug 12, 2014, at 10:02 AM, Andy Parker <[email protected]> wrote: > > On Mon, Aug 11, 2014 at 8:54 PM, Spencer Krum <[email protected]> > 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 [email protected]. > 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 [email protected]. 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.
