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.

> 
> 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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to