On 2014-06-08 16:56, Spencer Krum wrote:
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?
No, this is not for defaults, it is for assigning values to attributes.
Local defaults are set by setting attributes of an entry labeled with a
title that is a literal default.
- henrik
Thanks,
Spencer
On Wed, Aug 6, 2014 at 6:46 AM, Henrik Lindberg
<henrik.lindb...@cloudsmith.com <mailto:henrik.lindb...@cloudsmith.com>>
wrote:
On 2014-06-08 3:41, Reid Vandewiele wrote:
On Tue, Aug 5, 2014 at 4:11 PM, Henrik Lindberg
<henrik.lindberg@cloudsmith.__com
<mailto:henrik.lindb...@cloudsmith.com>
<mailto:henrik.lindberg@__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>
<mailto: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/
<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+unsubscribe@__googlegroups.com
<mailto:puppet-dev%2bunsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/__msgid/puppet-dev/lrtbji%24fqe%__241%40ger.gmane.org
<https://groups.google.com/d/msgid/puppet-dev/lrtbji%24fqe%241%40ger.gmane.org>.
For more options, visit https://groups.google.com/d/__optout
<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 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/CADt6FWPh4uaR%3DWHJq3JO7eFe9xQ8fugCJWiuSw-v%3DoEXcD0kyg%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-dev/CADt6FWPh4uaR%3DWHJq3JO7eFe9xQ8fugCJWiuSw-v%3DoEXcD0kyg%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/lru2bp%2436j%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
