On Wednesday, February 4, 2015 at 11:39:56 AM UTC-6, Hunter Haugen wrote:
> == Section 12.1 $unique_name = $name is unclear >>> I believe this was to describe how the continued use of $name throughout >>> a define can lead to confusion, as $name has no strong semantic meaning. >>> Thus a "good" example would be https://github.com/puppetlabs/ >>> puppetlabs-apache/blob/1.2.0/manifests/listen.pp#L2 and a bad example >>> would be... https://github.com/puppetlabs/puppetlabs-apache/blob/1.2.0/ >>> manifests/vhost.pp (because $name is scattered throughout the define >>> and has no definite meaning). >>> >>> >> >> I don't think "unique_name" has any more or less clear of a meaning in >> such contexts than does "name". Any lack of clarity is about which entity >> the name belongs to, and describing it as "unique" doesn't really help with >> that. >> >> Moreover, I observe that what you're saying the section is about is not >> at all how I read it. (Lack of clarity? Check.) I don't think we can talk >> about the wording details until we settle more generally what the section >> is trying to say. If you're confident about that (you don't sound it) then >> we can discuss the wording, but at this point my position would be that the >> section should just be deleted. >> > > I do know what I want, but I'm not a great wordsmith :(. The point of the > section was to say that "$name in a define doesn't have a semantic meaning, > so if you're going to use $name for anything programatic then assign it to > a semantically-meaningful variable for clarity's sake and use that > instead." But if you think that's not really a useful pattern then we could > delete the section. > > You're not making sense. If $name has no semantic meaning in a given context, then it is no more useful for initializing some other variable's value than for anything else. I do acknowledge that there is sometimes confusion about what $name means inside a defined type body. Typically that takes the form of thinking that within a resource declaration inside the defined type, $name would refer to the contained resource's name rather than to the name of the containing instance of the defined type. The proposed style point does not help with that particular issue, as it's more about scoping than about choice of variable names. Creating an alternative variable for the instance name is not particularly useful for many simple defined types, such as many that just wrap a plugin type. On the other hand, the stylistic pattern may be helpful in more complex defined types. In such cases, the alternative variable name *I* would choose for the instance name within a defined type 'module::foo' would be "foo_name". That at least addresses the main point of confusion (what is named), though it still does little for the scoping confusion (because confused users would still try to use $name). You could offer that pattern as a *suggestion*, but I don't think it should be a rule. As long as we're on defined type automagic variables, though, consider that there is also $title, which will always have the same value as $name for a defined type. It would be entirely reasonable for a style rule to designate one of those to always be used instead of the other. Absent such a rule, all the above considerations regarding $name also apply to $title. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/f623ece2-cd9a-45f0-9a7a-ae3a4d758e2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
