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 <john.bollin...@stjude.org> 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 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 > <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 tvaug...@onyxpoint.com -- 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 puppet-users+unsubscr...@googlegroups.com. 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.
