I think a metaparameter is a great solution. It has the advantage of feeling the most puppety, and can be successfully googled for.
I don't think I agree that attribute_hash is more descriptive than attribute_defaults, since, aren't we setting defaults? Thanks, Spencer On Wed, Aug 6, 2014 at 6:46 AM, Henrik Lindberg < [email protected]> wrote: > On 2014-06-08 3:41, Reid Vandewiele wrote: > >> On Tue, Aug 5, 2014 at 4:11 PM, Henrik Lindberg >> <[email protected] <mailto:[email protected]>> >> >> wrote: >> >> On 2014-05-08 18:24, Andy Parker wrote: >> >> >> My argument against using parenthesis is that parenthesis, are >> often >> read as "seldom necessary grouping". I believe that most >> programmers >> read them as usually only needed for fixing precedence problems, >> which >> is really what is happening here but it doesn't look like it. >> Based on >> that I can imagine that a common, and frustrating mistake would >> be: >> >> apache::vhost { $servername: $opts } >> >> And then confusion and anger and bug reports. >> >> >> Yeah, I think they are too subtle too (and hence the * =>). >> >> >> One more proposal :-) >> >> We could leave out the name part all together (i.e. drop the '*'). >> >> dalens' example would then look like this: >> >> >> apache::vhost { $servername: >> >> port => $port, >> ssl => $ssl, >> => $extra_opts, >> >> And if it is used for local defaults (or the only thing for a titled >> resource): >> >> file { default: => $hash } >> file { '/tmp/foo': => $hash } >> >> This works best if it is restricted to being the only attribute >> operation for a title, but looks a bit odd when presented in a list >> where there are also named (i.e. name => expression) operations. >> >> At least it is not a new operator. >> >> Is this better than * => or requiring parentheses ? >> >> >> - henrik >> >> >> >> I'm still not happy with either "* =>" or " =>". Both unnecessarily >> (imho) complicate the structure of the most basic building block in the >> Puppet language. >> >> On Tue, Aug 5, 2014 at 11:52 AM, David Schmitt <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> I like that piece of code as it is. Perhaps I would add a comment >> noting that $vhost_options is not allowed to override the >> base_vhost_options and give a reason for that. I needed to browse up >> to the parameter doc and think a bit about what that should mean. >> >> I do not think the whole sequence would be any better with some kind >> of special operator, except perhaps for the hash() thingy, which I >> conveniently ignore in the analysis, but assume it's doing some >> merging. >> >> Also, create_resources is google-able. To find the splat operator, >> one would either have to know it or think about the language >> reference and browse through the visual index or the operator chapter. >> >> >> Maybe solving for this use case would be better handled by implementing >> something that looks and feels like a metaparameter rather than trying >> to come up with new syntax. That approach would have the benefit of not >> complicating the language, and meet all of the functional requirements >> discussed so far. It would also be google-able. There would need to be >> some design around the choice of a name for the "metaparameter", but >> it's easy enough to demonstrate the concept with a stand-in like >> "attribute_defaults" or "attribute_hash". >> >> Example 1 (assuming behavior whereinmerging is OK, and that explicit >> parameter specification takes precedence): >> >> apache::vhost { $servername: >> port => $port, >> ssl => $ssl, >> attribute_defaults => $extra_opts, >> } >> >> Example 2 (assuming that merging is not OK, and that conflicts will be >> treated as duplicate parameter specification): >> >> apache::vhost { $servername: >> port => $port, >> ssl => $ssl, >> attribute_hash => $extra_opts, >> } >> >> My initial thought would be to choose and settle on one behavior and >> review an appropriate name, though it wouldn't be objectionable to >> support both. >> >> Does an operator/syntax gain us anything that this kind of >> metaparameter-like approach does not? >> >> The only negative implication of a meta-parameter-like approach is that > it requires a special reserved name. Currently attribute names can be any > valid name including keywords (except true and false, plus the names that > are already reserved for meta parameters). > > An operator does not add any other value. > > A small difference is that the meta attribute name may be used in > manifests that are evaluated by an older puppet. In those cases there would > be an error that "attribute_hash" is not a valid attribute name, as opposed > to a syntax error (if an operator is used). > > > Is taking a metaparameter-like approach still a language feature, or >> does that become an actual metaparameter? >> >> It becomes a language feature - otherwise the implementation of this > ripples through the entire system. > > > Visual review, for convenience: >> >> file { $title: * => $attributes; } >> file { $title: => $attributes; } >> file { $title: ($attributes); } >> file { $title: attribute_defaults => $attributes; } >> file { $title: attribute_hash => $attributes; } >> >> > Using "attribute_hash" is certainly a lot more descriptive. > > > - henrik > > -- > > 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/lrtbji%24fqe%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/CADt6FWPh4uaR%3DWHJq3JO7eFe9xQ8fugCJWiuSw-v%3DoEXcD0kyg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
