On 2014-12-08 19:47, Luke Kanies wrote:
On Aug 5, 2014, at 6:41 PM, Reid Vandewiele r...@puppetlabs.com
mailto:r...@puppetlabs.com wrote:
Visual review, for convenience:
file { $title: * = $attributes; }
file { $title: = $attributes; }
file { $title: ($attributes); }
file { $title:
On Aug 12, 2014, at 3:51 PM, Henrik Lindberg henrik.lindb...@cloudsmith.com
wrote:
On 2014-12-08 19:47, Luke Kanies wrote:
On Aug 5, 2014, at 6:41 PM, Reid Vandewiele r...@puppetlabs.com
mailto:r...@puppetlabs.com wrote:
Visual review, for convenience:
file { $title: * = $attributes; }
I would also like to propose that we use the metaparameter syntax for
defaults as well.
For example, rather than writing this:
#less readable
file {
default:
mode = '0666';
'/tmp/foo': ;
'/tmp/bar': ;
'/tmp/special':
mode = '0777';
}
One would write this:
#more readable
On 2014-07-08 20:09, Ben Ford wrote:
I would also like to propose that we use the metaparameter syntax for
defaults as well.
For example, rather than writing this:
#less readable
file {
default:
mode = '0666';
'/tmp/foo': ;
'/tmp/bar': ;
'/tmp/special':
mode = '0777';
}
One would write
On Thu, Aug 7, 2014 at 12:55 PM, Henrik Lindberg
henrik.lindb...@cloudsmith.com wrote:
On 2014-07-08 20:09, Ben Ford wrote:
I would also like to propose that we use the metaparameter syntax for
defaults as well.
For example, rather than writing this:
#less readable
file {
default:
On 2014-06-08 3:41, Reid Vandewiele wrote:
On Tue, Aug 5, 2014 at 4:11 PM, Henrik Lindberg
henrik.lindb...@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
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?
Thanks,
Spencer
On Wed, Aug 6, 2014 at
I really like the metaparameter approach. It's almost self documenting.
On Tuesday, August 5, 2014 6:41:40 PM UTC-7, Reid Vandewiele wrote:
Maybe solving for this use case would be better handled by implementing
something that looks and feels like a metaparameter rather than trying to
I hate to me too but I'm actually a pretty big fan of the metaparam too,
it's very readable and clear.
On Wed, Aug 6, 2014 at 11:41 AM, Ben Ford ben.f...@puppetlabs.com wrote:
I really like the metaparameter approach. It's almost self documenting.
On Tuesday, August 5, 2014 6:41:40 PM
On Aug 5, 2014 6:41 PM, Reid Vandewiele r...@puppetlabs.com wrote:
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,
}
Assuming
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?
On 2014-06-08 19:29, Wil Cooley wrote:
On Aug 5, 2014 6:41 PM, Reid Vandewiele r...@puppetlabs.com
mailto:r...@puppetlabs.com wrote:
Example 1 (assuming behavior whereinmerging is OK, and that explicit
parameter specification takes precedence):
apache::vhost { $servername:
port =
On 2014-07-08 1:18, Wil Cooley wrote:
On Wed, Aug 6, 2014 at 1:30 PM, Henrik Lindberg
henrik.lindb...@cloudsmith.com mailto:henrik.lindb...@cloudsmith.com
wrote:
$extra_opts = { $ssl = true, ... }
I assume you mean {ssl = true, ...}, and not the value of a
variable $ssl ?
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 position
On Tue, Aug 5, 2014 at 8:18 AM, Erik Dalén erik.gustav.da...@gmail.com
wrote:
On 5 August 2014 16:25, Reid Vandewiele r...@puppetlabs.com 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
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,
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
On Sunday, August 3, 2014 4:32:39 PM UTC-7, henrik lindberg wrote:
My main objection with create_resources function is that it is not a
natural progression from the language. When developing puppet code, you
start out with simple resources and use the syntax for creating them. As
you
On Mon, Aug 4, 2014 at 12:09 PM, Reid Vandewiele r...@puppetlabs.com
wrote:
I am concerned that adding additional operators to the language does in
fact take something away. As such, I do think that proposals to do so need
to require a very strong argument in order to proceed.
When I go out
So, I'm chiming in to say that I completely agree with Reid and Ashley.
As an end user, I want to hand off code that is clear and relatively easy
to read. I definitely do not want magic symbols (or I would have stuck with
PERL).
I'm OK with all of the concepts proposed but I would like more
On 2014-04-08 20:35, Trevor Vaughan wrote:
So, I'm chiming in to say that I completely agree with Reid and Ashley.
As an end user, I want to hand off code that is clear and relatively
easy to read. I definitely do not want magic symbols (or I would have
stuck with PERL).
I'm OK with all of the
This is certainly better than the new operator but the parenthesis are a
bit strange.
Isn't the title 'default' special enough to not have the parenthesis?
If not, then I can certainly live with the parenthesis syntax better than a
new operator (though support in the syntax checkers will be most
On 2014-05-08 1:08, Trevor Vaughan wrote:
This is certainly better than the new operator but the parenthesis are a
bit strange.
Isn't the title 'default' special enough to not have the parenthesis?
The functionality is not limited to the default title, and a literal
default is not a special
Sorry for the vagueness. I was referring to Geppetto, the Vim plugin, etc...
Random parenthesis are something that I think will be often overlooked
without some help.
Thanks,
Trevor
On Mon, Aug 4, 2014 at 7:16 PM, Henrik Lindberg
henrik.lindb...@cloudsmith.com wrote:
On 2014-05-08 1:08,
On 2014-03-08 22:30, Luke Kanies wrote:
On Jul 30, 2014, at 1:02 PM, John Bollinger john..bollin...@stjude.org
mailto:john.bollin...@stjude.org wrote:
[...]
Here are the tests for the future parser (as changed by the PR)
[thing ,resource, [thing]],
On 2014-03-08 22:18, Luke Kanies wrote:
On Jul 28, 2014, at 6:43 AM, John Bollinger john..bollin...@stjude.org
mailto:john.bollin...@stjude.org 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
On 2014-03-08 22:22, Luke Kanies wrote:
On Jul 28, 2014, at 7:33 AM, Henrik Lindberg henrik.lindb...@cloudsmith.com
wrote:
On 2014-28-07 8:34, Luke Kanies wrote:
On Jul 24, 2014, at 5:32 PM, Andy Parker a...@puppetlabs.com
mailto:a...@puppetlabs.com wrote:
Howdy,
Henrik, David, Erik,
On 2014-07-31 22:16, John Bollinger wrote:
[good points]
Just a quick note that I'm mainly agreeing with John's points: Automatic
(and inconsistent) stringification of non-string-titles is weird and
confusing, thus should be avoided. Automatic flattening of
arrays-of-strings is weird, but
On Fri, Aug 1, 2014 at 12:39 AM, David Schmitt da...@dasz.at wrote:
On 2014-07-31 22:16, John Bollinger wrote:
[good points]
Just a quick note that I'm mainly agreeing with John's points: Automatic
(and inconsistent) stringification of non-string-titles is weird and
confusing, thus should
On Wednesday, July 30, 2014 4:21:37 PM UTC-5, Andy Parker wrote:
On Wed, Jul 30, 2014 at 1:02 PM, John Bollinger john.bo...@stjude.org
javascript: wrote:
On Tuesday, July 29, 2014 1:23:09 PM UTC-5, Andy Parker wrote:
On Thu, Jul 24, 2014 at 5:32 PM, Andy Parker an...@puppetlabs.com
On Tuesday, July 29, 2014 1:23:09 PM UTC-5, Andy Parker wrote:
On Thu, Jul 24, 2014 at 5:32 PM, Andy Parker an...@puppetlabs.com
javascript: wrote:
Howdy,
Henrik, David, Erik, John, and others have been having some pretty epic
conversations around resource expressions, precedence,
On Wed, Jul 30, 2014 at 1:02 PM, John Bollinger john.bollin...@stjude.org
wrote:
On Tuesday, July 29, 2014 1:23:09 PM UTC-5, Andy Parker wrote:
On Thu, Jul 24, 2014 at 5:32 PM, Andy Parker an...@puppetlabs.com
wrote:
Howdy,
Henrik, David, Erik, John, and others have been having some
On 2014-30-07 23:21, Andy Parker wrote:
Exactly. And that is why I'm a little nervous about just disallowing all
of these types. However, it will now fail fast and so the migration path
to the new system is: get rid of warnings, run with --parser future, fix
errors, check that your systems still
On Thu, Jul 24, 2014 at 5:32 PM, Andy Parker a...@puppetlabs.com wrote:
Howdy,
Henrik, David, Erik, John, and others have been having some pretty epic
conversations around resource expressions, precedence, order of evaluation,
and several other topics. What kicked all of that off was us
Definitely excited to see this stuff moving forwards.
On Thursday, July 24, 2014 5:32:13 PM UTC-7, Andy Parker wrote:
Henrik took all of the ideas and started trying to work out what we could
do and what we couldn't. Those are in a writeup at
On Tue, Jul 29, 2014 at 11:54 AM, Reid Vandewiele r...@puppetlabs.com
wrote:
Definitely excited to see this stuff moving forwards.
On Thursday, July 24, 2014 5:32:13 PM UTC-7, Andy Parker wrote:
Henrik took all of the ideas and started trying to work out what we could
do and what we
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 think create_resources is
used simply because you can. Instead, it is because you do not
statically know the
On 2014-28-07 8:34, Luke Kanies wrote:
On Jul 24, 2014, at 5:32 PM, Andy Parker a...@puppetlabs.com
mailto:a...@puppetlabs.com wrote:
Howdy,
Henrik, David, Erik, John, and others have been having some pretty
epic conversations around resource expressions, precedence, order of
evaluation, and
On 2014-25-07 3:32, Spencer Krum wrote:
I'm not sure if this is the correct time to mention this, but I wonder
if you considered arrays of hashes in decision eight?
I guess they are not really arrays of hashes but whatever this is:
[
'/root/file1' = {'owner' = 'root'},
'/root/file1' =
Okay. Thanks.
On Fri, Jul 25, 2014 at 5:39 AM, Henrik Lindberg
henrik.lindb...@cloudsmith.com wrote:
On 2014-25-07 3:32, Spencer Krum wrote:
I'm not sure if this is the correct time to mention this, but I wonder
if you considered arrays of hashes in decision eight?
I guess they are not
On Thu, Jul 24, 2014 at 6:04 PM, Henrik Lindberg
henrik.lindb...@cloudsmith.com wrote:
On 2014-25-07 2:32, Andy Parker wrote:
DECISION SEVEN
undef is not allowed as a title
Not much to say here. notify { undef: } fails (or anything that
evaluates to undef)
DECISION SEVEN AND 3/4
On Thursday, July 24, 2014 7:32:13 PM UTC-5, Andy Parker wrote:
Howdy,
Henrik, David, Erik, John, and others have been having some pretty epic
conversations around resource expressions, precedence, order of evaluation,
and several other topics. What kicked all of that off was us looking
On Friday, July 25, 2014 11:25:37 AM UTC-5, Andy Parker wrote:
On Thu, Jul 24, 2014 at 6:04 PM, Henrik Lindberg
henrik@cloudsmith.com javascript: wrote:
On 2014-25-07 2:32, Andy Parker wrote:
DECISION SEVEN
undef is not allowed as a title
Not much to say here. notify {
On 2014-25-07 22:43, John Bollinger wrote:
On Thursday, July 24, 2014 7:32:13 PM UTC-5, Andy Parker wrote:
Howdy,
Henrik, David, Erik, John, and others have been having some pretty
epic conversations around resource expressions, precedence, order of
evaluation, and several
On 2014-25-07 2:32, Andy Parker wrote:
DECISION TWO
Resource instantiations are value producing expressions
The expression based grammar that puppet 4 will be based on changed
almost everything into a general expression, which allowed a lot of
composition that wasn't possible before. This
I'm not sure if this is the correct time to mention this, but I wonder if
you considered arrays of hashes in decision eight?
I guess they are not really arrays of hashes but whatever this is:
[
'/root/file1' = {'owner' = 'root'},
'/root/file1' = {'owner' = 'nibz'},
]
Right now we often use
46 matches
Mail list logo
