> On Aug 12, 2014, at 3:51 PM, Henrik Lindberg <henrik.lindb...@cloudsmith.com>
> wrote:
>
>> 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.
I'm not specifically saying this is the right answer, but if your goal
is to be more explicit and clear, and to add syntax for this case and
other data manipulation needs, then I think these are in a better
direction than the other proposed syntaxes. Again, directionally
right, even if the specifics aren't exact.
> 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)
Urgh, yuck. Is this intentional/needed, or is precedence changeable
with minimal/no cost?
> 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).
So maybe it could kill multiple birds with one stone, then. :)
If we went this kind of route, we'd want to find a way to not require
parens, IMO. Although maybe that would be ugly enough that it would
discourage use, which might be the right behavior. :)
>> # 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.
Would it be simple to implement without the parens?
And note that I'm far more concerned about simple to use than simple
to implement. If we have to do 10x the engineering but our users have
to do 1/10th the thinking to use it, then it's easily worth the
investment.
>> 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
Yeah, I thought about that, too. No idea if that would work for the
parser, or if it would be too confusing with the spaceship operator.
Again, parens make the whole thing not so great. And you need a way
to differentiate between the "replace if they're there" and "only add
these if the param isn't set" cases.
>> 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.
This kind of inconsistency seems like the perfect example of something
we should be trying to fix.
I think the problems in Puppet's language stem more from inconsistency
than from incompleteness[1]. You've already done a lot of good work
to improve that, and I think this is another area where we could make
smaller improvements in completeness and much bigger improvements in
consistency, which would solve nearly everyone's problems by making a
cleaner, clearer design that was a bit more powerful but not too much.
1 - Note that just about my favorite book in the world is Gödel Escher
Bach, so I can talk about this topic for far longer than anyone else
cares. I might be making total gibberish here.
--
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/806547761205608839%40unknownmsgid.
For more options, visit https://groups.google.com/d/optout.
