The hyphen is commonly used in naming, and is as good a practice as any.
For example, it is used in:
- names in LISP
- certain element and attribute names in XML and various XML languages such
- CSS property names and values
- various filesystem path conventions
- various URL conventions
So hyphens are fine by me. Indeed they seem to me to be, in some way, nicer
than the alternatives; but that’s just taste.
Data is data. When dealing with data, it should be obvious that it’s data.
Node attributes are data, so when dealing with node attributes, it should
be obvious that what you’re dealing with is data. In Ruby, symbols are
typically reserved for denoting named parts of your program - e.g.
metaprogramming, reflection, and named arguments to methods -, while
methods are typically reserved for behavior rather than data, even if the
behavior is simply to fetch data. But strings are the universal language of
data, in Ruby as well as in other languages, and in Chef as well as in
other Ruby systems.
Simply put, using strings for node attributes makes it dead obvious to all
concerned that what you’re dealing with is normal, run-of-the-mill,
non-fancy, unadulterated, pure data.
From a memory perspective, using symbols in your code is not problematic.
The problem is symbolizing strings willy-nilly that come from input or
other external sources. E.g., in a web apps, symbolizing strings that come
from the browser is an invitation to be DoS’d, since anybody can just
iterate the same request but substituting all possible strings into the
request until your app runs out of memory and crashes. (It also opens up
the thread-safety-vs-slow-lock problem.) But most people using Chef won’t
run into that problem.
On Tue, Oct 16, 2012 at 4:41 PM, Hedge Hog firstname.lastname@example.org:
On Wed, Oct 17, 2012 at 7:16 AM, Paul Graydon email@example.com
Why add unnecessary constraints?
What do we gain by stopping people from using -'s and other marks in
To my mind using strings facilitates, if not encourages, a bad
practice in naming: using minus, dash, etc. in attribute names.
It seems that if we go down the path of endorsing strings then we
should give up accessing attr data via methods and maybe even symbol
If not then there will be a growing population of names with
Eventually, and I really do mean taking a long term view, this means
your cookbook/shop cannot adopt a practice/convention of accessing by
method name. or you have to sanitize strings before
IMO, this benefit to discouraging use of strings a key names is large
enough to make the short term pain worthwhile.
Hopefully I have not misunderstood something.
It doesn’t particularly affect me either way because I don’t do it, but
not sure I see a particular benefit in restricting such practices.
On 10/16/2012 10:13 AM, Jesse Nelson wrote:
I agree with the too noisy sentiment. I think that being consistent in
a cook is good, but I personally prefer symbols and enforcing a no -'s
in attrib names. Of course there are exceptions that you run into, and
you have to use strings. I find symbols easier on the eyes and
On Tue, Oct 16, 2012 at 12:21 PM, Jeremy Voorhis firstname.lastname@example.org
As a maintainer of in-house and 3rd party cookbooks for my
find FC001 too noisy to be useful. We haven’t yet modernized our repo
include every single cookbook as a self-contained repo, and in some
find little benefit in doing so. New cookbooks follow FC001 and other
practices that didn’t yet exist or weren’t widely known at the time, so
rule is mostly ignored for now and we test for the desired outcome
On Tue, Oct 16, 2012 at 11:28 AM, Joshua Timberman <email@example.com
We want to hear from you: which way of using node attributes do you
prefer? Please take this single question survey:
This is in response to a longer twitter discussion today on the
The survey will be left open for awhile, letting as many people as
answer. We really value this feedback.
If you want an explanation of why this rule came about the way it did,
our rationale for preferring strings to symbols, see this issue in the
If you’re going to be at the Chef summit next week, I’m happy to
this in greater detail, too :-).
πόλλ’ οἶδ ἀλώπηξ, ἀλλ’ ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
Archilochus, Greek poet (c. 680 BC – c. 645 BC)