Hi,
thanks for keeping the ball rolling!
On 2014-08-06 02:51, Andy Parker 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.
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
I would like them kept. These are items that I often have to fall back into
Ruby to use and it's nice to have them exposed. Otherwise, it's either an
inline template or a custom function (doing the exact same thing).
Trevor
On Tue, Aug 5, 2014 at 9:01 PM, Andy Parker wrote:
> It has been broug
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 us
It has been brought to my attention that there are a number of the
functions that were added as part of the "iteration in the puppet language"
work that there isn't any kind of general agreement on their value.
I think the list of functions in question is:
* map
* reduce
* filter
* slice
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
expressi
On 2014-05-08 18:24, Andy Parker wrote:
On Tue, Aug 5, 2014 at 8:18 AM, Erik Dalén mailto:erik.gustav.da...@gmail.com>> wrote:
On 5 August 2014 16:25, Reid Vandewiele mailto:r...@puppetlabs.com>> wrote:
On Mon, Aug 4, 2014 at 3:18 PM, Henrik Lindberg
mailto:henrik.lindb...@c
So to summarize, this is our plan for Rubocop:
- We propose to enable AndOr cop in small chunks, giving preference to
those files/directories that are heavily in development.
- For AndOr, the conclusion seems to be to avoid keywords completely, and
ensure that the instances where they are used a
On 2014-08-05 12:19, Erik Dalén wrote:
On 3 August 2014 22:18, Luke Kanies mailto:l...@puppetlabs.com>> wrote:
On Jul 28, 2014, at 6:43 AM, John Bollinger
mailto:john.bollin...@stjude.org>> wrote:
On Friday, July 25, 2014 5:15:30 PM UTC-5, henrik lindberg wrote:
We r
On Tue, Aug 5, 2014 at 8:18 AM, Erik Dalén
wrote:
> On 5 August 2014 16:25, Reid Vandewiele wrote:
>
>> On Mon, Aug 4, 2014 at 3:18 PM, Henrik Lindberg <
>> henrik.lindb...@cloudsmith.com> wrote:
>>
>>>
>>> So, to summarize: The use of * => as an operator is not liked but the
>>> concept of bein
On 5 August 2014 16:25, Reid Vandewiele wrote:
> On Mon, Aug 4, 2014 at 3:18 PM, Henrik Lindberg <
> 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
>>
On Mon, Aug 4, 2014 at 3:18 PM, Henrik Lindberg <
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 po
On 3 August 2014 22:18, Luke Kanies wrote:
> On Jul 28, 2014, at 6:43 AM, John Bollinger
> wrote:
>
>
>
> On Friday, July 25, 2014 5:15:30 PM UTC-5, henrik lindberg wrote:
>>
>>
>> We reasoned that we already have create_resources in frequent use to
>> solve real issues, so it is needed. I don't
13 matches
Mail list logo
