1) I think that this is going to be used to develop highly complex and
unmaintainable code but I see the use case. +1
2) Yes, I think this would be nice in some complex cases but I don't mind
create_resources. Of course, I create resource on the fly in my Types so I
may not be the best judge....
3) I think that, should you use a hash for parameters, it's something
*really* clear like 'parameter_hash' or 'param_hash'. Fundamentally, every
concrete chunk of code that I've seen with this in it has not thrilled me
in terms of understandability by other users. I agree with a point made in
the other thread that trying to search on *=> isn't going to get you very
far.
service { 'apache': param_hash => $param_hash } # Nice an descriptive, easy
to search and probably what you're going to guess anyway
Q: "What's the parameter hash thing?"
A: "Oh, param_hash"
Trevor
On Tue, Aug 5, 2014 at 8:51 PM, Andy Parker <a...@puppetlabs.com> wrote:
> I'm pulling this discussion out into a new thread so that we can become
> more focussed. I'm also going to start a thread about one other topic that
> has been brought to my attention so that a decision can be reached.
>
> In this thread I'd like to get to a decision about two aspects of resource
> expressions:
>
> 1. Whether to allow expressions in the type position ($a { hi: })
> 2. Whether to allow using hashes as resources parameters
> 3. If we allow hashes as resource parameters, what token introduces it
> (no introducing token isn't an option because of implementation
> constraints).
>
> The use case for number 1 is to provide determining the exact type of a
> resource at runtime. An example would be a module that had different
> implementations for debian vs redhat. It can then use parts of its self
> like so:
>
> apache::install::$osfamily { 'something': }
>
> Note: I'm not promoting this or saying that this kind of construction
> should appear everywhere, but it is a feature that isn't available in the
> language at the moment.
>
> The use case for number 2 is determining dynamically what parameters need
> to be included. In fact I saw a question just recently where someone tried
> to do (something like):
>
> service { 'apache':
> if $control_service {
> ensure => running
> }
> enabled => true
> }
>
> That could be done instead as:
>
> $params = if $control_service {
> { ensure => running }
> } else {
> { }
> }
> service { 'apache':
> * => $params;
> default:
> enabled => true
> }
>
> A second use case is to provide a way of allowing local defaults to be
> reused across multiple resources. And a third one was presented by Erik.
>
> Are these use cases invalid or not needed? If not, how should they be
> solved? There is create_resources. Is that really a good solution? I ask
> that in all seriousness given that the only purpose of the puppet language
> is to construct catalogs of resources to manage configurations and the
> current syntax for those fundamental elements are so inflexible that we had
> to add a function to leave the language for slightly more advanced resource
> creation scenarios.
>
> Puppet Labs has a UX department that is at the ready to perform any user
> testing or usability analysis that anyone thinks might be valuable to
> answer these questions. If we can work out what kinds of questions there
> are we can definitely get some study done.
>
> 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:
>>
>>> On Tue, Aug 5, 2014 at 8:18 AM, Erik Dalén <erik.gustav.da...@gmail.com
>>> <mailto:erik.gustav.da...@gmail.com>> wrote:
>>>
>>> On 5 August 2014 16:25, Reid Vandewiele <r...@puppetlabs.com
>>> <mailto:r...@puppetlabs.com>> wrote:
>>>
>>> On Mon, Aug 4, 2014 at 3:18 PM, Henrik Lindberg
>>> <henrik.lindb...@cloudsmith.com
>>> <mailto:henrik.lindb...@cloudsmith.com>> wrote:
>>>
>>>
>>> So, to summarize: The use of * => as an operator is not
>>> liked but the concept of being able to set attributes from a
>>> hash is. Unfortunately, it is not possible to directly allow
>>> an expression at the position in question, there must be a
>>> syntactical marker.
>>>
>>> As pointed out earlier, the * => was thought to read as
>>> "any_attribute => from_these_values", but I totally grok if
>>> people have an allergic reaction.
>>>
>>> We can do this though:
>>>
>>> file { default: ($hash) }
>>>
>>> This works because it is impossible to have an attribute
>>> name in parentheses.
>>>
>>> In use:
>>>
>>> file (
>>> default : ($my_file_defaults + { mode => '0666' });
>>> '/tmp/foo': ;
>>> '/tmp/bar': ;
>>> }
>>>
>>> Is that better? No new operator, but you have to use
>>> parentheses around the expression.
>>>
>>> We can naturally also revert the functionality, but it seems
>>> it is liked conceptually.
>>>
>>>
>>> - henrik
>>>
>>>
>>>
>>> I think the parenthesis are far preferable over *=>. That isn't
>>> to say I like them - I don't particularly. But the functionality
>>> is desirable, and if it's a matter of a technical limitation
>>> then parenthesis are a Good Enough (TM) compromise from the more
>>> ideal direct use of a hash.
>>>
>>>
>>> I really prefer the use of * => over the parenthesis. Especially if
>>> you need to merge things into the hash. For example look at this
>>> example:
>>>
>>> # using parenthesis hash style
>>> class foo (
>>>
>>> $servername = $::fqdn,
>>> $port = 80,
>>> $ssl = false,
>>> $extra_opts={},
>>>
>>> ) {
>>> apache::vhost { $servername: ($extra_opts + {
>>>
>>>
>>> port => $port,
>>> ssl => $ssl,
>>> })
>>>
>>> }
>>> }
>>> # using * =>
>>> class foo (
>>>
>>> $servername = $::fqdn,
>>> $port = 80,
>>> $ssl = false,
>>> $extra_opts={},
>>>
>>> ) {
>>> apache::vhost { $servername:
>>>
>>> port => $port,
>>> ssl => $ssl,
>>> * => $extra_opts,
>>>
>>>
>>> }
>>>
>>> }
>>>
>>>
>>> The behavior that we worked out doesn't allow having the splat along
>>> with the other parameters, the reason being that it isn't clear what is
>>> meant by that. You had in your head that port and ssl are overridden by
>>> extra_opts (possibly because they come first?), but another, completely
>>> reasonable interpretation is that it is the other way around (port and
>>> ssl override extra_opts because they are explicitly given. In order to
>>> remove any of that confusion the current specification and
>>> implementation doesn't allow mixing. That can, I think, be changed.
>>>
>>> In the current implementation this would need to be:
>>>
>>> apache::vhost { $servername:
>>> * => $extra_opts + { port => $port, ssl => $ssl }
>>> }
>>>
>>> IMO the *=> is way more readable (as gist here if formatting is
>>> screwed up for you:
>>> https://gist.github.com/dalen/57b37b80a9ba1879b78c). This is quite
>>> similar to what I linked earlier that I am doing in
>>> https://github.com/spotify/puppet-puppetexplorer/blob/
>>> master/manifests/init.pp#L89-L97
>>> So it is not just a contrived example.
>>>
>>>
>>> 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
>>
>> --
>>
>> 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/lrrobu%245b1%241%40ger.gmane.org.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Andrew Parker
> a...@puppetlabs.com
> Freenode: zaphod42
> Twitter: @aparker42
> Software Developer
>
> *Join us at PuppetConf 2014 <http://www.puppetconf.com/>, September
> 22-24 in San Francisco*
> *Register by May 30th to take advantage of the Early Adopter discount
> <http://links.puppetlabs.com/puppetconf-early-adopter> **—**save $349!*
>
> --
> 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/CANhgQXvw3AxSQgrUQQKpMyrCNPkdci9gytum-C832C7_q8v6xQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-dev/CANhgQXvw3AxSQgrUQQKpMyrCNPkdci9gytum-C832C7_q8v6xQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
--
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/CANs%2BFoUOynxCDRbo_pPFv_cq9A6o-uNcxMexEWAbFA0Vu9GMEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
