Feedback on the behavior of +=, -=, +, and -

[Andy Parker]

I'm looking over PUP-2972, which is closely related to PUP-489, and is specified (but changeable, hence this email!) at https://github.com/puppetlabs/puppet-specifications/blob/master/language/expressions.md#-operator-8 and https://github.com/puppetlabs/puppet-specifications/blob/master/language/expressions.md#-operator

PUP-2972 has information about what I found by looking at modules from the forge and on github to see how += is being used right now. The purpose of this is to try to make += consistent with +, the behavior of + to be much more predictable, and -= is added by analogy with += existing.

What I'd like to know is: 

  * Do the semantics specified make sense?

  * The recommendation of PUP-2972 suggests just dropping += (and -=) because they are confusing. I'm reluctant to do that since it is already in use and has been around for a while. Is it useful to keep them around?

The most notable change in functionality is that += won't work for string concatenation anymore, because + doesn't do string concatenation. Instead you'll need to use string interpolation ($a = "$a$b").

--

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!

[Trevor Vaughan]

I tend to avoid += since it's a "magic" edge case in variable scope.

If all of my code takes the strict view that variables are immutable, I am much less likely to confuse anyone who reads my code later.

This does end up with stupid code like $l_var = $var + ['foo'], but that can't be helped while preserving clarity.

Now, I would LOVE the ability to manipulate all variables within scope. That would be very nice and then I would vote for keeping += around.

That would allow for things like:

if empty($foo) {

  $foo = 'bar'

}

Instead of:

if empty($foo) {

  $l_foo = 'bar'

}

else {

  $l_foo = $foo

}

Which is irritating.

Trevor

--
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/CANhgQXsf-qieFaFOoYo7WkS%2BsdeveLsBGO3pgZpsUV2o5hAjLg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[Henrik Lindberg]

On 2014-09-08 21:12, Trevor Vaughan wrote:
> I tend to avoid += since it's a "magic" edge case in variable scope.
>
> If all of my code takes the strict view that variables are immutable, I
> am much less likely to confuse anyone who reads my code later.
>

Just to be clear, the += does *not* mutate, it creates a new variable
that shadows the original in an outer scope.

> This does end up with stupid code like $l_var = $var + ['foo'], but that
> can't be helped while preserving clarity.
>
> Now, I would LOVE the ability to manipulate all variables within scope.
> That would be very nice and then I would vote for keeping += around.
>
> That would allow for things like:
>
> if empty($foo) {
> $foo = 'bar'
> }
>
> Instead of:
>
> if empty($foo) {
> $l_foo = 'bar'
> }
> else {
> $l_foo = $foo
> }
>
> Which is irritating.
>
> Trevor
>

- henrik
--

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

[Trevor Vaughan]

Yeah, I know that it doesn't actually mutate. But it *feels* like it does, which is the issue.

Trevor

--
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/ls60q9%24s0d%241%40ger.gmane.org.

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

[Reid Vandewiele]

On Sunday, August 10, 2014 7:11:11 PM UTC-7, Trevor Vaughan wrote:

Yeah, I know that it doesn't actually mutate. But it *feels* like it does, which is the issue.

Trevor

For this reason I would advocate omission of += and -= from the language.

The problem is not that the behavior is inconsistent or that it breaks any -rules-, per se. The problem is that the behavior is non-intuitive and not just in a difficult-to-guess-at way, but in a can-directly-confuse-users way. Yes, $fqdn is potentially different from $::fqdn but if we're trying to guide people into a mindset of "variables are immutable" we should not muddy the waters with syntax that looks contradictory to that paradigm - especially if all it gains us is saving a few characters being typed.

I believe this constitutes a compelling design reason to remove += and -=.

~Reid

[Andy Parker]

I can agree to that. Reid, I suppose that you've encountered people being confused by this when working with new puppet users?

I just chatted with Hunter and Ashley on #puppet-dev and they also agree that += should be taken out back and shot. We also discussed how best to remove it, and the conclusion that we came to was:

  * leave it as-is in the current parser. Don't even issue a deprecation warning

  * mention += going away in the docs

  * Remove the implementation from the future parser

  * Retain the ability in the future parser to parse += and -=

  * When += or -= are encountered, the validation step will issue an error (this allows us to issue a much better error than just "Syntax Error")

  * Remove all mention of += and -= from the specification. This isn't part of the language, the implementation is only dealing with it to produce a good error message for the transition.

I just checked a dump of the forge from yesterday and += is still only used in the 2 modules that I mentioned in the ticket, so it hasn't proliferated as far as I can tell.

 

~Reid

--
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/4a0b0503-dd0a-408f-b856-afe91374a924%40googlegroups.com.

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

--

[William Van Hevelingen]

I think there should be a deprecation warning in current parser so that users are aware it's going away. It will make migration from Puppet 3 to Puppet 4 if users can fix all the warnings before making the plunge.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANhgQXsdCPtq0NgQvkei1xje6cPjucTUQpfNbbBf12WJSJ969w%40mail.gmail.com.

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

--

Thanks,

William

[Andy Parker]

On Wed, Aug 13, 2014 at 6:02 PM, William Van Hevelingen <wva...@gmail.com> wrote:

I think there should be a deprecation warning in current parser so that users are aware it's going away. It will make migration from Puppet 3 to Puppet 4 if users can fix all the warnings before making the plunge.

I was reluctant to add the warning because of the feedback that I've gotten that we've gone a little warning overboard. In fact, in this particular case, the warning isn't as needed because the future parser in 3.7 (and the regular one in 4) will emit an error that provides information about what is going on (it isn't just a syntax error, it actually parses += and -= and says that they are no longer supported).

 

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAEXKxLz_%3DN8i%3D416YpQX%2B3-2TydtSVZLoaa43Hff41XeyHsb9g%40mail.gmail.com.

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

[Ben Ford]

We've never taught these operators in training

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANhgQXvA2EZ_ugK4hG2TaFkEUwrsYi4M5ENmte7tS8iO%3DtJXWA%40mail.gmail.com.

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

--

Ben Ford | Training Solutions Engineer 
Puppet Labs, Inc.
926 NW 13th Ave, Suite #210
Portland, OR 97209

509.592.7291
ben....@puppetlabs.com