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 <[email protected]> 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 <
> [email protected]> wrote:
>
>> On 2014-05-08 18:24, Andy Parker wrote:
>>
>>> On Tue, Aug 5, 2014 at 8:18 AM, Erik Dalén <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> On 5 August 2014 16:25, Reid Vandewiele <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> On Mon, Aug 4, 2014 at 3:18 PM, Henrik Lindberg
>>> <[email protected]
>>> <mailto:[email protected]>> 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 [email protected].
>> 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
> [email protected]
> 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 [email protected].
> 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
[email protected]
-- 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 [email protected].
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.
