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.
> >
> > "*=>" 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';
}
> 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.
>
> >
> > DECISION EIGHT
> >
> > An array as a title expands to individual resource instantiation
> > expressions with titles of the elements of the array.
> >
> > This isn't really too far off from the current semantics, no real
> > change here.
> >
> >
> >
> > Is there any change /at all/ there with respect to what current Puppet
> > already supports? (I don't see any, but you've spooked me.)
> >
> Current implementation silently skips undef entries, balks at an undef
> title (not in an array), but allows other types than Strings as
> resulting individual titles (with the weird stringification taking place
> that we talked about above). Hence, "not too far off". Feel better now?
>
Yes, thank you.
John
--
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/4dd40d37-4467-4720-8d76-90539b815687%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
