Issue #10506 has been updated by Henrik Lindberg.

Description updated

----------------------------------------
Bug #10506: Naming rules are inconsistent
https://projects.puppetlabs.com/issues/10506#change-97320

* Author: Henrik Lindberg
* Status: Accepted
* Priority: Urgent
* Assignee: eric sorenson
* Category: language
* Target version: 3.x
* Affected Puppet version: 
* Keywords: usability syntax
* Branch: 
----------------------------------------
The rules for naming of classes is inconsistently applied to different language 
concepts.

* It is allowed to name a class using *NUMBER* (e.g. '0', '0.0', '0477', 
'0x1f', '1.3e-2').
* A dollar variable is parsed with the regular expression 
`%r{\$(::)?([-\w]+::)*[-\w]+}` and can thus never refer to a variable in a 
class named with a  '.' (period) in the name. (Update: A hyphen in the variable 
is no longer allowed, in 3.x it is gone in the regexp, and in 2.7.20? it is 
possible to turn it on, but also getting a deprecation warning).
* A *NAME*, *CLASSREF*, or *CLASSNAME* is parsed with` 
%r{((::)?[a-z0-9][-\w]*)(::[a-z0-9][-\w]*)*}` and can also not contain a '.' 
(period). Update, now that hyphens in variables are not allowed, it should also 
be disallowed in names.
* Regular expression matching injects values into variables `$0` - `$n` 
(although not directly clashing since a class is typically not referenced with 
a variable, it is still confusing to see say `$0::1`, when $0 is a regexp match)
* Class defaults can be set using a class reference (each segment starts with 
upper case letter in a fully qualified name), this is strange when name is 
numeric (how do you write an upper case '1'?). Compare:

using words:

    class one($a) { class two($b) {} }
    One { a=>10 }
    One::Two {b=>20}

using numbers:

    class 1($a) { class 2($b) {} }
    1 { a=>10 }
    1::2 {b=>20}

The second example (naturally) results in:
    Could not parse for environment production: All resource specifications 
require names at /private/tmp/test.pp:2 on node xxx


* A separate issue is that assignment to `$0` - `$n` may not take effect (the 
variable is still undefined) in some cases.
* The documentation does not seem to mention the fact that classes may have 
numerical names (the stricter rules are shown in several places).

I suggest that:
* Numerical names should be deprecated
* Assignment to `$0` - `$n` should be illegal (reserved for regular expression 
matches)

In contrast, if trying to fix this by adding '.' (period) as valid in 
variables, a lot of string interpolation will break (in similar ways to how the 
altered string interpolation rules regarding '-' (hyphen) breaks existing code).
The interpolation issues could be resolved by deprecating the interpolation 
short form (i.e. interpolating without braces), but that may be considered a 
more serious imposition (even if recommended as best practice) - i.e. that 
`"Hello $name"` must be written `"Hello ${name}"`.

It seems like 2.8 would be a good candidate for more stringent rules since 
dynamic scoping of variables will be deprecated and people do have to inspect 
their code and deal with naming/reference issues.
    
The rules in the documentation has been updated and now state that variables 
may be capitalized. Thus `$Boo` is allowed, but since a qualified name must 
have segments that start with lower case, this only applied to the last part of 
the name - i.e. `$Foo::Bar` is not accepted. When variables are used to define 
parameters, they may not be capitalized (since the rsource instance statement 
does not allow upper case attribute names. This is inconsistent and it would be 
best if capitalize variable names were not allowed.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to