I'm not sure if this is the correct time to mention this, but I wonder if
you considered arrays of hashes in decision eight?
I guess they are not really arrays of hashes but whatever this is:
[
'/root/file1' => {'owner' => 'root'},
'/root/file1' => {'owner' => 'nibz'},
]
Right now we often use arrays of hashes with the create_resources function
when we need to specify parameters. This is similar to the effect of how
arrays passed into resources as title behave.
I think it would be awesome if we could pass what we currently pass into
create_resources into resource instantiations.
Thanks,
Spencer
On Thu, Jul 24, 2014 at 6:04 PM, Henrik Lindberg <
[email protected]> wrote:
> On 2014-25-07 2:32, Andy Parker wrote:
>
>> DECISION TWO
>>
>> Resource instantiations are value producing expressions
>>
>> The expression based grammar that puppet 4 will be based on changed
>> almost everything into a general expression, which allowed a lot of
>> composition that wasn't possible before. This didn't change resource
>> expressions. Resource expressions could not be assigned ($a = notify
>> {hi:}). That is being changed. This removes several odd corners in the
>> grammar and makes it all more consistent. It is also highly unlikely
>> that it would be removed later (principle 1). The value of a resource
>> expression is a reference to the created resource, or an array of
>> references if there is more than one.
>>
>> QUESTION: should the value always be an array of references? That would
>> make it much more predictable.
>>
>> DECISION THREE
>>
>> Resource instantiation expressions will not be allowed in dangerous
>> locations
>>
>> Once resource expressions can be placed anywhere there are a few places
>> where they would actually just do more harm than good (principle 2). One
>> example is as a parameter default (define a($b = notify {hi:}) {}).
>>
>> DECISION FOUR
>>
>> The LHS of a resource *instantiation* expression can be an expression
>>
>> What?!? This means you can do:
>>
>> $a = notify
>> $a { hi: }
>>
>> Once again, in clearing up odd cases in the grammar this is opened up to
>> us. This is a very powerful feature to have available. Since this is
>> very useful and fits well into the grammar I don't see this being a
>> temporary thing that would then have to go away later (principle 1).
>>
>> DECISION FIVE (how many of these are there?)
>>
>> A resource with a title of default provides the default parameter
>> values for other resources in the same instantiation expression.
>>
>> Thanks to David Schmitt for this idea!
>>
>> Since we aren't going to change the behavior of resource default
>> expressions (Notify { ... }) it seems like there needs to be something
>> done to provide a better, safer way of specifying defaults. This will
>> allow:
>>
>> notify {
>> default: message => hi;
>> bye: }
>>
>> The result will be a resource of type Notify with title bye and message
>> hi. It is highly unlikely that this will go away (principle 1) as it is
>> syntactic sugar for specifying the parameters for every resource.
>>
>> DECISION SIX
>>
>> There will be a splat operator for resource instantiation expressions
>>
>> To make the default resources (decision five) really useful there needs
>> to be a way to reuse the same values across multiple defaults. The
>> current, dangerous, semantics of resource default expressions skirt this
>> issue by making defaults part of the (dynamic) evaluation scope. In
>> order to make the default resources nearly as useful but much safer, we
>> need to add a way to allow reuse of defaults across multiple resource
>> instantiation expressions explicitly (principle 2).
>>
>> $owner_mode = { owner => andy, mode => '777' } # gotta make it secure
>> file { default: *=> $owner_mode;
>> '/home/andy/.bashrc': ;
>> '/home/andy/.ssh/id_rsa': ;
>> }
>>
>> file { '/etc/passwd': *=> $owner_mode }
>>
>> As a side note, do you see what can now be done?
>>
>> $a = notify
>> $b = hi
>> $c = { message => bye }
>> $a { $b: *=> $c }
>>
>> DECISION SEVEN
>>
>> undef is not allowed as a title
>>
>> Not much to say here. notify { undef: } fails (or anything that
>> evaluates to undef)
>>
>>
> DECISION SEVEN AND 3/4
>
> A title expression must result in a String value, or Array of String
> values. No regular expressions, hashes, booleans, numbers etc.
>
> No magic turning a title into a string if it is not.
>
> 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. It is only to call out that we are formalizing that as the
>> semantics. An empty array ends up being a noop (no resources
>> instantiated). An array that contains undef will produce an error (see
>> decision seven). The value default can be an element of the array and
>> will produce the default section for the resources being instantiated
>> (as pointless as that seems since they will all have the same body).
>>
>> DECISION NINE
>>
>> Decisions two through eight do not apply to resource default or
>> resource override expressions.
>>
>> Just to make it clear that decision one still holds.
>>
>> CONCLUSION
>>
>> I think that covers it all. This will be reflected by a revert to some
>> code, modifying the grammar, adding some new evaluation capabilities,
>> including tests, and updating the specification. All of this is falling
>> under PUP-501, PUP-511, and PUP-2898 in some way shape or form.
>>
>> This email was to record the decisions; make them public; double check
>> that Henrik, Joshua and I all had the same understanding of them; and
>> give another chance to everyone to weigh in.
>>
>> I did have one question that I uncovered as I was writing this up. Some
>> feedback on that would be great as well.
>>
>> --
>> Andrew Parker
>> [email protected] <mailto:[email protected]>
>>
>> Freenode: zaphod42
>> Twitter: @aparker42
>> Software Developer
>>
>> *Join us at PuppetConf 2014 <http://www.puppetconf.com/>, September
>> 22-24 in San Francisco*
>> /Register by May 30th to take advantage of the Early Adopter discount
>> <http://links.puppetlabs.com/puppetconf-early-adopter> //—//save $349!/
>>
>>
>> --
>> 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]
>> <mailto:[email protected]>.
>>
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-dev/CANhgQXu3HVrWJrTnMgYvbY6%
>> 3DR8B%3DvVgts2Uqmwjtj6eJRJsH7g%40mail.gmail.com
>> <https://groups.google.com/d/msgid/puppet-dev/CANhgQXu3HVrWJrTnMgYvbY6%
>> 3DR8B%3DvVgts2Uqmwjtj6eJRJsH7g%40mail.gmail.com?utm_medium=
>> email&utm_source=footer>.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> Visit my Blog "Puppet on the Edge"
> http://puppet-on-the-edge.blogspot.se/
>
>
> --
> 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/lqsaff%2438h%241%40ger.gmane.org.
>
> 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/CADt6FWNcOa2vaxx_vNn%2BNTX1tmngeF2KEi0mspQcCxUBrh3mYg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
