Issue #6745 has been updated by Krzysztof Wilczynski.
Hello, [...] > It means that you can not use return value of nil in your custom functions to > indicate some error etc which feels rather uncomfortable to anyone familiar > with ruby. I would rather detect a potential error in the body of the function and raise Puppet::ParseError where appropriate. You do want to fail and let a potential user know that something is going awry... over returning NilClass value. To be honest, most of Puppet DSL users are not Ruby developers (emphasis on "most"), plus said DSL has its specific approach to certain things. It is also not a Turing-complete language AFAIK :) For instance, numeric (integer and float) values are passed as strings into the "newfunction" block unless they are a negative values, etc. And it is how it always was, and you have to live with it :-) Anyhow, the point I am trying to make is ... that it is better to raise Puppet::ParseError when you expect to return NilClass value over simply returning nil for user to handle, which might even not be feasible in Puppet DSL. My outlook on such things. P.S. Technically, even Facter has no concept of returning nil, so to speak, from its facts ... Am I right? :) KW ---------------------------------------- Bug #6745: Puppet needs a better undef/way to handle nil's from custom functions https://projects.puppetlabs.com/issues/6745 Author: Rich Rauenzahn Status: Re-opened Priority: Normal Assignee: Nigel Kersten Category: Target version: Affected Puppet version: Keywords: Branch: It appears to me that undef isn't really a real type in puppet. If I pass something that is undef to a custom function and ask Ruby for its class, it says it is a String. It almost seems like undef is just an alias for "". It would be nice if it was a distinct type. More importantly (see farther below), nil bubbled up from Ruby code ought to be evaluated correctly within puppet. Let's look at the type mappings: define test { $type1 = vmw_type("") # this func returns foo.class.to_s notice("string is $type1") $array = ["a", "b"] $type2 = vmw_type($array) notice("array is $type2") $dict = { "key" => "value" } $type3 = vmw_type($dict) notice("dict is $type3") $bool = true $type5 = vmw_type($bool) notice("true is $type5") $undef = undef $type4 = vmw_type($undef) notice("undef is $type4") } test { "foo": } [rich@rich-fedora tests]$ puppet --modulepath=/Perforce /main/machines/puppet/puppetmaster/modules/ tests/vmw_type.pp notice: Scope(Test[foo]): string is String notice: Scope(Test[foo]): array is Array notice: Scope(Test[foo]): dict is Hash notice: Scope(Test[foo]): true is TrueClass notice: Scope(Test[foo]): undef is String So either undef is really a string, or it was evaluated to a string before being passed to the custom function. Related, when a custom function returns a nil, puppet doesn't know what to do with it at all, and I think that nil ought to be mapped to this undef type: [rich@rich-fedora tests]$ puppet --modulepath=/Perforce/main/machines/puppet/puppetmaster/modules/ vmw_json_parse.pp [...] $foo3 = vmw_json_parse("bad|,'':") # this just calls the PSON parse, returns nil if fails to parse. $type = vmw_type($foo3) notice("type=$type") if $foo3 == "" { notice("foo3 is ''") } if $foo3 == undef { notice("foo3 is undef") } if !$foo3 { notice("foo3 is not true") } if $foo3 { notice("foo3 is true") } [...] The output below shows that NilClass is not an empty string, or is it undef, but is in fact true. notice: Scope(Test[a]): type=NilClass notice: Scope(Test[a]): foo3 is true Now, we could have puppet walk dictionaries, arrays, and scalars returned from custom functions and transform nil scalars into "" (or undef), but it would seem smarter to change the internal guts of puppet to treat NilClass as undef (is there really any such thing as undef in the internal code? Or is it really just an alias for ""?) So, in summary: (a) Puppet should handle nils returned from custom functions (b) Would this be a good time to also map undef to a ruby data type, like nil? -- 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.
