On 2014-12-08 19:47, Luke Kanies wrote:
On Aug 5, 2014, at 6:41 PM, Reid Vandewiele <r...@puppetlabs.com
<mailto:r...@puppetlabs.com>> wrote:
Visual review, for convenience:
file { $title: * => $attributes; }
file { $title: => $attributes; }
file { $title: ($attributes); }
file { $title: attribute_defaults => $attributes; }
file { $title: attribute_hash => $attributes; }
Sorry for joining the party late; I'm clearly not quite on the same
email cadence. :/
I think there are some other interesting middle grounds. In particular,
we could add explicit merge operations, like other languages have for
hashes:
# Make some functions for merging a hash into a resource
file { $title: mode => 644 }.merge($attributes) #destructively merge
file { $title: mode => 644 }.default($attributes) #prefer specified
attributes
Yes sure, but we have earlier frowned on mutating functions.
The syntax that you used as an example will almost work, but the
resource expression has such low precedence that it cannot be directly
combined with a '.', if you put it in parentheses it will work though.
(file {$title: mode => '0644'}).merge($attributes)
You can write such a function now and use with the future parser (in the
version that is to be released in 3.7. In 3.6 future parser the syntax
would more complex since resource creation is not an expression (cannot
be assigned to anything etc. not without jumping through a hoop).
Also, a resource creation can create multiple resources, so the produced
value can be an array of resources, the function would need to take that
into account (apply the hash to all).
Basically, this moves the Resource Override expression in the language
to be a function that operates on a resource reference, or an array of
resource references. (BTW the Resource Override expression is the source
of many grammatical problems, and I would love to get rid of it).
# Alternative: Make operators for merging
file { $title: mode => 644 } & $attributes # Or something like that
We already use + for merging, so that could be used to merge resources
as well. Again, they have to be parenthesized.
(file {$title: mode => '0644' }) + $attributes
This would be simple to implement.
In other words, get rid of the whole concept of explicitly specifying
defaults, and also get rid of anything inside the curlies, and just
modify the resource in place with a function or operator.
In my head, the bitwise operators seemed like an obvious operator set to
use; in practice, it looks, um, questionable at best. At the least, any
of the above statements would be expected to affect the resource, and
it's tough to say that's obvious from the syntax.
i.e. append these attributes:
(file {$title: mode => '0644' }) << $attributes
I do like the explicitness of it, though.
The biggest issue is the immutability aspect. The language is currently
inconsistent. By using a collector you can override any resource value,
but you are not allowed to override with the resource override
expression (only set unset values).
We later have to tackle the requirement that it should be possible to
restate the same resource (and possibly amend to it) from multiple
sources, and we do have to have to find a different approach. Only
mutability leads to wild west - however managed to run last gets to set
the values. (In order to support this, the catalog model needs to change
as it can currently only track one containment). This is work planned to
start after Puppet 4.0 BTW.
- henrik
--
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
<mailto:puppet-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/69F21637-06EA-428A-AA02-982777591D4F%40puppetlabs.com
<https://groups.google.com/d/msgid/puppet-dev/69F21637-06EA-428A-AA02-982777591D4F%40puppetlabs.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/lse5oa%24o0h%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
