RFC - Grammar quirks I want to remove...

[Henrik Lindberg]

Hi,

Boolean Attributes
---
The current grammar (and future parser) accepts an attribute operation
with the name being a Boolean value. Have you ever seen $true or $false
as parameters in a class, define or type?

i.e.

define foo ($true) {
}

foo { the_foo: true => false }

Can we get rid of this, it is bad enough that all other keywords can be
used (if, unless, case, class, define, etc. etc.)

Exported with whitespace
---

The grammar allows the two @@ in an exported resource expression
to be separated by whitepsace. (Both current and future parser).

i.e.

@
# yes, this works
#


@

notify { exported1: message => 'wat' }

@ /* its a little bit odd... */ @

notify { exported2: message => 'wat' }

This creates two exported notify resources.

Can we disallow whitespace between the two @ ?

- henrik



--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

[Peter Meier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Can we get rid of this, it is bad enough that all other keywords
> can be used (if, unless, case, class, define, etc. etc.)

Couldn't we ban them as well? I think in most other "programming"
languages this won't work as well.

> Can we disallow whitespace between the two @ ?

+1

~pete

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlPI0SoACgkQbwltcAfKi38+gACghnfJRYt+oiXKNJv4I2zj3zIj
gfIAoJ8HGIb/LIN8rx+OgqQJ4eWTf0Ug
=eHQd
-----END PGP SIGNATURE-----

[Felix Frank]

On 07/18/2014 09:47 AM, Peter Meier wrote:
>> Can we get rid of this, it is bad enough that all other keywords
>> > can be used (if, unless, case, class, define, etc. etc.)
> Couldn't we ban them as well? I think in most other "programming"
> languages this won't work as well.

I second this.

>> > Can we disallow whitespace between the two @ ?
> +1

And this.

[Andy Parker]

On Fri, Jul 18, 2014 at 12:47 AM, Peter Meier <peter...@immerda.ch> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Can we get rid of this, it is bad enough that all other keywords
> can be used (if, unless, case, class, define, etc. etc.)

Couldn't we ban them as well? I think in most other "programming"
languages this won't work as well.

We tried that, accidentally, when we added some new keywords. Lots of things broke. In fact one of the core types uses a keyword: exec uses unless.

 

> Can we disallow whitespace between the two @ ?

+1

~pete

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlPI0SoACgkQbwltcAfKi38+gACghnfJRYt+oiXKNJv4I2zj3zIj
gfIAoJ8HGIb/LIN8rx+OgqQJ4eWTf0Ug
=eHQd
-----END PGP SIGNATURE-----

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/53C8D12F.7030101%40immerda.ch.

For more options, visit https://groups.google.com/d/optout.

--

Andrew Parker

an...@puppetlabs.com

Freenode: zaphod42

Twitter: @aparker42

Software Developer

Join us at PuppetConf 2014, September 22-24 in San Francisco

Register by May 30th to take advantage of the Early Adopter discount —save $349!

[Henrik Lindberg]

On 2014-18-07 17:42, Andy Parker wrote:
> On Fri, Jul 18, 2014 at 12:47 AM, Peter Meier <peter...@immerda.ch
> <mailto:peter...@immerda.ch>> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > Can we get rid of this, it is bad enough that all other keywords
> > can be used (if, unless, case, class, define, etc. etc.)
>
> Couldn't we ban them as well? I think in most other "programming"
> languages this won't work as well.
>
>
> We tried that, accidentally, when we added some new keywords. Lots of
> things broke. In fact one of the core types uses a keyword: exec uses
> unless.
>

Yeah, there are a few that makes sense; "class", "unless", "define",
"type", "inherits", "not" comes to mind as possibly meaningful names
(there may be others). Since that is like half of them, we could just
support all of them. The keywords true/false are different in that they
produce boolean values. There is no great harm in continuing to support
them; I just find it odd to name an attribute "true" or "false", and we
already have confusion over "false" vs. false.

[Andy Parker]

Yes, getting rid of false and true makes sense since those are literal values (like 1 is a literal integer value).

 

- 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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/lqbg28%24oei%241%40ger.gmane.org.

For more options, visit https://groups.google.com/d/optout.

[R.I.Pienaar]

----- Original Message -----
> From: "Peter Meier" <peter...@immerda.ch>
> To: puppe...@googlegroups.com
> Sent: Friday, July 18, 2014 8:47:59 AM
> Subject: Re: [Puppet-dev] RFC - Grammar quirks I want to remove...
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > Can we get rid of this, it is bad enough that all other keywords
> > can be used (if, unless, case, class, define, etc. etc.)
>
> Couldn't we ban them as well? I think in most other "programming"
> languages this won't work as well.

yeah, curious too why it's only true/false that's worthy of removal and
not the rest :)

[David Schmitt]

On 2014-07-18 03:00, Henrik Lindberg wrote:
> Hi,
>
> Boolean Attributes
> ---

> Exported with whitespace
> ---

Kill both with fire.

Please.


Regards, David

[Jason Antman]

+10, shipit for both.

setting trusted_node_data turns "$facts" into a reserved variable and triggers a nice warning as such if you try to use it. Seems that such behavior should happen automatically for any reserved word (in puppet4, I assume).

--
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+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/53CA2FE4.5020900%40dasz.at.