On 3 August 2014 22:18, Luke Kanies <l...@puppetlabs.com> wrote:
> On Jul 28, 2014, at 6:43 AM, John Bollinger <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)
>
>
>> 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.
> 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CAAAzDLcUss5MsGEvZsSUJUtxFdQ6vK%3Dr1e1wC33fB24YMXXAow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
