On 2014-08-05 12:19, Erik Dalén wrote:
On 3 August 2014 22:18, Luke Kanies <l...@puppetlabs.com <mailto:l...@puppetlabs.com>> wrote: On Jul 28, 2014, at 6:43 AM, John Bollinger <john.bollin...@stjude.org <mailto:john.bollin...@stjude.org>> wrote:On Friday, July 25, 2014 5:15:30 PM UTC-5, henrik lindberg wrote: We reasoned that we already have create_resources in frequent use to solve real issues, so it is needed. I don't think create_resources is used simply because you can. Instead, it is because you do not statically know the type, or you want to decide which attributes to set based on calculations you made. Both of those require create_resources function. Now it moves into the language. For what it's worth, every use of create_resources() that I have ever come across or thought about has involved a resource type that is statically known. The usual reason for create_resources() is that the *identities* and properties of the resources need to be dynamically determined. That is, if I need or want to resort to create_resources() then it's /usually/ because I don't know statically which specific resources (of a known type) need to be managed. Sometimes I /also/ don't know which properties need to be managed or maybe what their target values should be, but that's secondary.Exactly. This is the more normal case, and is the one we should optimize for. And, IMO, the one that create_resources works just dandily for. I don’t see the need to promote a function to syntax in this case.> > "*=>" looks weird, even for Puppet. What about contracting it to "*>", > parallel to the plussignment operator (+>) and to the ordinary value > binding operator (=>)? > The rationale is that you normally have: name => value Now, you do not have names, and * is often used as a wildcard/splat/ "split it up", implied, the name is picked from the hash, and you may want to line them up: file { default: * => value ; foo: mode => '0777' ; } Does that make it feel better? Somewhat, yes. I at least get the mnemonic angle, but it still seems weird. Is this one operator "*=>" or two "*" "=>"? If one, then are you really going to permit splitting the operator into two tokens? If two, then is this splat operator the same one you described elsewhere? And what is the splat's operand in this context? With this new, highly expressional approach, it seems like there should be a way to do without the *=> altogether. I mean, if you have a property name / value hash, then why shouldn't you be able to plunk it down undecorated inside a resource instantiation expression? E.g. file { default: $file_defaults; foo: mode => '0777'; } or file { default: $general_file_defaults, owner => 'ted'; foo: mode => '0777'; } or even file { default: $general_file_defaults, $mymodule_file_defaults, owner => 'ted'; foo: mode => '0777'; }Yeah, I’m not at all a fan of the ‘* => foo’ syntax. It seems strange in both the lexer and the parser, and it strikes me as a far large change to the system without a large return. If we conclude we need significantly more power in the resource parameters, then I’d prefer to do something like formally treat it as a hash, and support some kind of hash operations there. E.g., something like: file { default: $some_defaults + $other_defaults + {owner => ‘ted’}; foo: mode => ‘0777’ } This expands how we think about the RHS of a resource declaration, but I think it’s more generically powerful and requires far less specialized syntax. As an example where this kind of expressiveness is needed: https://github.com/spotify/puppet-puppetexplorer/blob/master/manifests/init.pp#L89-L97 Here I used it to allow the user to simply pass a hash with any additional apache::vhost parameters as a parameter instead of exposing all of them (and the usage of the hash() function is because puppet 3.x doesn't allow variables as keys in hashes...). But either of those proposed solutions could be used there I guess (*=> or default: pointing to a hash)
I like that piece of code as it is. Perhaps I would add a comment noting that $vhost_options is not allowed to override the base_vhost_options and give a reason for that. I needed to browse up to the parameter doc and think a bit about what that should mean.
I do not think the whole sequence would be any better with some kind of special operator, except perhaps for the hash() thingy, which I conveniently ignore in the analysis, but assume it's doing some merging.
Also, create_resources is google-able. To find the splat operator, one would either have to know it or think about the language reference and browse through the visual index or the operator chapter.
The first proposal was: title: (expr) Then, just use the splat operator: title: *expr But then it became weird, because it is a special kind of splat that applies to the entire expression - that felt more confusing. But haven't you still got a special kind of splat? I think all you've done is alter the spelling to distinguish it from the other splat -- which is better than not -- but it's still kinda confusing.Agreed. -- 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 <mailto:puppet-dev+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/D4F608CD-67BF-4E4C-BA68-E54BF1A10678%40puppetlabs.com <https://groups.google.com/d/msgid/puppet-dev/D4F608CD-67BF-4E4C-BA68-E54BF1A10678%40puppetlabs.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- Erik Dalén -- 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 <mailto:puppet-dev+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAAAzDLcUss5MsGEvZsSUJUtxFdQ6vK%3Dr1e1wC33fB24YMXXAow%40mail.gmail.com <https://groups.google.com/d/msgid/puppet-dev/CAAAzDLcUss5MsGEvZsSUJUtxFdQ6vK%3Dr1e1wC33fB24YMXXAow%40mail.gmail.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout.
-- * Always looking for people I can help with awesome projects * G+: https://plus.google.com/+DavidSchmitt Blog: http://club.black.co.at/log/ LinkedIn: http://at.linkedin.com/in/davidschmitt -- 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/53E127E0.4090502%40dasz.at. For more options, visit https://groups.google.com/d/optout.
