Update the attributes syntax #195
Conversation
- We've never done most of what we agreed to do. - We argued out a few points in #77 that we should capture 1. we decided that functional arguments foo("bar", "baz") are better than method chaining, and this was incorporated into the Chef 12 attributes updates. 2. we decided on strings over symbols in the arguments. 3. we also decided that RFC #18 needed to be amended because the implications of foo("bar.baz") were poor. - This also argues for the addition of an option (-F offhand blindly copied from awk, dunno if that'll really work) to deal with cases where '.' as a field separator causes issues -- because typing arrays on the command line is incredibly poor UX and nobody has bothered to implement it. - This officially demotes the dot-syntax to a commandline workaround, and pushes *argv style / array formatting to the forefront for ruby APIs.
|
I think that the principle of Consistent Consistency for the sake of Consistency has led us astray and that we have a spec with syntax that nobody in their right mind wants to use, and nobody in their right mind wants to implement, and which we've actually decided against doing in another PR that we've never gotten around to merging. So what we have here is Consistent Inconsistency. The splat notation and array-like notation are preferred in ruby code wherever they can use and is the PRIMARY way of writing attributes. The dot notation is demoted to a SECONDARY way of writing attributes which we utilize if and only if the primary way of writing them becomes awkward (like on the command line). We also include a somewhat more sensible way of overriding the separation character to any user defined character rather than forcing people to write array syntax on the commandline as a fallback. The primary purpose of RFC 018 seems to be to address confusion over 'foo.bar' vs. 'foo_bar' vs. 'foo:bar' vs. 'foo/bar' methods of addressing attributes. We still pick 'foo.bar' as the default way of doing that and state that the other syntax still should change (although we still have not done any of this work). |
|
Also I believe we had this argument in the Chef 12 attributes PR and we decided to violate RFC 018 because we hated what it did to the syntax. |
|
For example comments on stringy dots here: #77 (comment) |
|
Adam's comment that boils down the discussion and vote we had in IRC about strings-vs-symbols: #77 (comment) |
|
I approve this message @chef/rfc-editors |
better than method chaining, and this was incorporated into
the Chef 12 attributes updates.
the implications of foo("bar.baz") were poor.
copied from awk, dunno if that'll really work) to deal with
cases where '.' as a field separator causes issues -- because typing
arrays on the command line is incredibly poor UX and nobody has
bothered to implement it.
and pushes *argv style / array formatting to the forefront for
ruby APIs.