On 2014-06-08 3:41, Reid Vandewiele wrote:
On Tue, Aug 5, 2014 at 4:11 PM, Henrik Lindberg
<henrik.lindb...@cloudsmith.com <mailto:henrik.lindb...@cloudsmith.com>>
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 <da...@dasz.at
<mailto:da...@dasz.at>> 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 puppet-dev+unsubscr...@googlegroups.com.
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.
