On Tue, Aug 5, 2014 at 4:11 PM, Henrik Lindberg <
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> 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?
Is taking a metaparameter-like approach still a language feature, or does
that become an actual metaparameter?
Visual review, for convenience:
file { $title: * => $attributes; }
file { $title: => $attributes; }
file { $title: ($attributes); }
file { $title: attribute_defaults => $attributes; }
file { $title: attribute_hash => $attributes; }
~Reid
--
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/CAHNFGkOFB5GNuRQmcv7m2q9u%3DBNxAYkyT3chj4i56ZicgkR_Jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
