Issue #14654 has been updated by Reid Vandewiele. Subject changed from :undef should not be synonymous with the empty string in Puppet if/case/selector to 'undef' should not be synonymous with the empty string in Puppet DSL if/case/selector Description updated
Clarifying issue description to try and make it more obvious that this doesn't really have anything to do with ruby code. This issue was intended to be purely about the Puppet DSL, but since language like :undef (leading colon like a ruby symbol) was used, it was easy to miss that. ---------------------------------------- Feature #14654: 'undef' should not be synonymous with the empty string in Puppet DSL if/case/selector https://projects.puppetlabs.com/issues/14654#change-68861 Author: Reid Vandewiele Status: Duplicate Priority: Normal Assignee: Category: Target version: Waldorf Affected Puppet version: Keywords: Branch: This feature request is a spin-off of the resolution of #8778. In trying to trace back through undef-related tickets in order to get a better idea of what the intention moving forward is, I unearthed issues #4692, #6621, #6745, #8783, and #13210. Most of those tickets were about exposing the :undef symbol in ruby (custom functions, templates) but in a completely biased fashion I came up with a few quotes that I think are more generally applicable to the use of 'undef' in the Puppet DSL. Paul Berry in #4692: > We’d intended for :undef to only be used internally within Puppet to > distinguish between undefined variables and variables whose values are the > empty string. Matt Robinson in #8783: > Puppet’s concept of undef seems fairly easy to confuse with empty string, > Ruby’s nil, and often gets exposed through the symbol :undef when it > shouldn’t. It doesn’t seem to me like there’s an overall philosophy behind > undef and how it should be treated in Puppet. Chris Price in #13210: > [...] there are cases in the world where there is a meaningful semantic > distinction between “null” and an empty string (plenty of precedent for this > in relational databases, etc.), and [...] our current implementation > explicitly prevents users from handling that distinction. It's because of the latter-most sentiment that code I am familiar with deliberately checks to see if values are undef rather than empty strings (`if $val == undef`), and expects there to be a difference. These checks all break starting with Puppet 2.7.15 as a result of the #8778 resolution. The style guide currently recommends against checking to see if a value is undef, suggesting instead that a picked-from-a-hat 'UNSET' string should be used in class parameter defaults and that DSL code should be written to handle that conventionally defined string rather than using a language-level "null" check. The fact that this used to work (with :undef) was a bug. Fixing the #8778 bug resulted in Puppet more consistently enforcing the inconsistency of 'undef' in the Puppet DSL. Consider the following example which for 2.7.15rc1 or greater demonstrates a situation in which :undef is already not synonymous with the empty string. notify { "if message is undef, the title will be used instead": message => undef, } if "" == undef { notify { "then this message should not be empty": message => "", } } ## Feature Request ## In order to allow users to account for the meaningful distinction between "null" and an empty string, 'undef' should not be synonymous with the empty string in Puppet DSL if/case/selector. For if/case/selector checks, it should be that undef == undef, but nothing else. undef != '' and '' != undef. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
