Hi,
On 2012-25-08 1:02, Nick Fagerlund wrote:
Yeah that reply isn't coming back. Anyway, I was totally hoping you'd
chime in with some holes you found. :)
Comments below...
On Friday, August 24, 2012 6:33:01 AM UTC-7, Henrik Lindberg wrote:
- How do I create strings that span multiple lines? (Since there is no
string concatenation operator 'x' + 'y' does not work). Can I write a
string that continues on the next line? If so, is the newline included
or not? Can I tell it to not include the newline? How is the line-break
encoded - if it is CR-LF in the pp-file, does the string contain
that at
runtime?
>
Added this! Line breaks are preserved, line break format is preserved
(so whatever you used in the file, that's what you get in your strings,
I don't like it either), you can use \n to get literal Unix line breaks,
but you can't use \r\n to get Windows ones because \r doesn't exist.
There isn't an ignore-whitespace option for strings.>
So, I guess you really have to use a template file instead if you want
something long and/or need more control over whitepsace.
- Can I write more complex expressions in an interpolation? Can I do
something like "The sum is ${$a + $b}", and if that is the case, is it
possible to have any expression interpolated (including nested strings
with interpolation)?
Nope! Thanks for reminding me about this, I remember trying to make
Puppet do this and being disappointed.
The thing is that it is supported in the parser (at least IIRC, but I
have not checked the last couple of months if anything changed). So the
question is if it is supposed to be in the language or not even if not
implemented correctly (i.e. language bug, or runtime bug?).
- The compiler allows ${a} without double quotes - which is a string
interpolation of $a. Which IIRC is slightly different than using $a
directly (getting an empty string if $a is undefined). I don't recall
seeing that in the documentation on the first read through.
If the parser allows this, it's getting blocked elsewhere in the system,
because Puppet definitely fails compilation hard if you try to use
${var} outside a double-quoted string.
Makes sense, and I should adjust Geppetto validation. It now accepts
${var} to have the same meaning as "${var}". One wonders why it is in
the grammar in the first place - maybe just a bug, or to give an
opportunity to say "${var} must be placed in a double quoted string?
- IIRC, Use of numerical variables $0 - $9 as a result of regular
expression matching was not mentioned. When talking about variables I
think it is worth noting that you should not use $0 - $9 for anything
else (or you may be surprised as the regexp match creates an inner
scope
where these variables refer to match results). (IMO use of $0-$9 should
be reserved for that purpose and they should not be assignable).
Ahhh good call. Actually, I just tested and it looks like assigning
directly to $\d is a no-op??? That's pretty wild. Anyway, putting them
in as reserved variable names.
- Arrays and Hashes are mutable; which is either an bug or a language
feature. While it is not allowed to directly change a variable, it can
be indirectly modified if it refers to an array or hash. Great if the
documentation can clarify if this is a supported feature or should be
avoided. i.e. $a = [1,2,3] $a[0] = 10. (IMO, this is problematic as any
logic can refer to the variable and assign to an entry - at least
last I
tried).
D:< EWW. "Problematic" is putting it mildly, especially since behavior
is inconsistent between arrays and hashes. (Both can add, only arrays
can reassign to existing indexes.) But I'd better document it anyhow.
The thing is, if arrays and hashes are immutable (as they should be),
there is no meaning to have [] operator produce a Lvalue at all - i.e.
can't assign something to the result. The only possible interpretation
of say $a[3]= 10 when they are immutable is to create a new variable $a
with an array assigned where 0-2 are undefined and 3 is assigned to 10.
Seems like a completely useless construct.
Passing arrays and hashes to functions is naturally a potential danger.
- henrik
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
