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
a...@puppetlabs.com <mailto:a...@puppetlabs.com>
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 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/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 puppet-dev+unsubscr...@googlegroups.com.
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.

Reply via email to