When I think of $name, I define it as this: https://docs.puppetlabs.com/guides/custom_types.html#namevar
In other words: I need a unique string, this is it and I'll use it where I need uniqueness so that my resources don't collide. But, as is pointed it out, it is actually meaningless beyond that usually. So, $unique_string = $name would be as accurate as I could make it in many cases. I would just make sure people know what it's for and don't make any assumptions about it whatsoever. Trevor On Thu, Feb 5, 2015 at 10:34 AM, jcbollinger <[email protected]> wrote: > > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/f623ece2-cd9a-45f0-9a7a-ae3a4d758e2a%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-users/f623ece2-cd9a-45f0-9a7a-ae3a4d758e2a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CANs%2BFoUWEaguyR1AEfZhNRkWhH9rS1TogPjXDuA%3DEF3Z2ZjJMQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
