Jira (PUP-3117) Resource Expression Enhancements

[Henrik Lindberg (JIRA)]

Title: Message Title

Henrik Lindberg commented on an issue   Re: Resource _expression_ Enhancements We now have the results of the UX research and have discussed and decided to go ahead with the feature as it is currently specified. The PR-3024 contains fixes for the outstanding issues that were put on hold until a decision had been made. We based the decision on the following reasoning: None of the test pilots had any issues guessing / recognizing that a * as an attribute name implies "all" / "everything" The * => $hash syntax for unfolding can follow the current formatting rule "align on arrow" "Googlability" was not an issue for any of the test pilots, they either came up with other words for the concept / idea, or would go to Puppet's (excellent) documentation and navigate to the relevant section (resource _expression_). We did not pick the runner up of using "attributes_hash" instead of the * based on the following reasoning: There is no indication that it is different from the other attributes, and that it is different from meta parameters. You would simply have to know this (which you only can if you know all the existing attribute names and meta parameters). There is nothing indicating that it does not hold the value; i.e. you cannot later lookup the "attributes_hash" parameter. This means that users have to learn that there is the concept of meta parameters that are available on all resources, but then also learn that one of them is special. All test pilots found both the local defaults, and the ability to unfold a hash to be useful. We did not test the allowed left hand side expressions. We decided to make it more strict that what is on master before PR-3024. It is not specified to statically validate that: it is a Qualified name (e.g. notify, file It is a Qualified reference (e.g. Notify, File It is an AccessExpression with a left _expression_ being a QualifiedReference (e.g. Resource[file], Resource[$x] This allows advanced users the opportunity to still have the ability to do a dynamic reference, while keeping regular users safe for unintentional strange effects and getting error messages that require knowledge that the left hand side can be any _expression_. The requirement to use the Resource type, gives users reading-code a clue to what is going on when reading someone else's advanced code. The keyword 'class' At runtime the _expression_ must evaluate to a CatalogEntry that is not title specific (i.e. Notify[hi] is not allowed) We decided to keep the specified and implemented behavior where the set of attribute names assigned to in a resource body must be unique as a silent override masks errors. If the effect of a default is wanted; that is what the local defaults is for. This way concepts are clearly separated. The specification has already been updated with this information. Add Comment   Puppet / PUP-3117 Resource _expression_ Enhancements We are awaiting the result of the UX research on the enhancements to the Resource _expression_. Depending on the outcome, we get to either keep the implementation as is, adjust it slightly or remove the now available feature(s) of: * local defaults * splatting a hash This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.