Skip to content

Loosen the restrictions of upcase and allow for recursion of the objects... #419

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 2, 2015

Conversation

cyberious
Copy link
Contributor

... and only worry if the object responds to upcase

@cyberious
Copy link
Contributor Author

Hey @elyscape, thanks for your feedback on the latest upcase enhancement, I know there was talk about why we needed it. The reason is so that we can get the keys however the user passes in the object whether it is 'grant', 'Grant' or 'GRANT' or any type of permutation. Hope this captures some of your thoughts. Also I had some of my own, like do we care what kind of object it is if it responds to upcase, symbols don't in ruby 1.8.7 but they do in 1.9.3 and 2.x

@elyscape
Copy link
Contributor

This will fail if you pass in a hash that contains a numeric type anywhere inside it. I think the best thing to do would be to validate that the initial object passed in as either an Array, a Hash, or something that responds to upcase and then hand off the recursion to a helper function that does the actual work.

@@ -21,18 +21,18 @@ module Puppet::Parser::Functions

value = arguments[0]

unless value.is_a?(Array) || value.is_a?(String) || value.is_a?(Hash)
unless value.is_a?(Array) || value.is_a?(Hash) || value.respond_to?(:upcase)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the spacing changes here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IDE, generated white spaces

@elyscape
Copy link
Contributor

As a side note, why are we checking that the number of arguments passed in is at least 1? Shouldn't we be checking that it's exactly 1, considering we only use the first argument?

@cyberious
Copy link
Contributor Author

I agree we should check to see if we are being passed at least one argument, didn't notice it was missing.

@elyscape
Copy link
Contributor

No, we are checking to see if we're being passed at least one argument, but I'm asking why we're not instead checking to see if we're being passed exactly one argument. That is, where we currently have:

raise(Puppet::ParseError, "upcase(): Wrong number of arguments " +
                            "given (#{arguments.size} for 1)") if arguments.size < 1

it would make more sense if we had:

raise(Puppet::ParseError, "upcase(): Wrong number of arguments " +
                            "given (#{arguments.size} for 1)") if arguments.size != 1

@cyberious
Copy link
Contributor Author

Instead of this check we use arity and ensure that we are only ever passed one parameter. This PR #249 actual does this for all of the functions but waiting for Puppet 4 to merge and slate for Stdlib 5

@cyberious cyberious force-pushed the master branch 2 times, most recently from 521339f to 9efe194 Compare March 2, 2015 17:34
raise(Puppet::ParseError, 'upcase(): Requires an ' +
'array, string or hash to work with')
'array, hash or object that responds to upcase in order to work')
end

if value.is_a?(Array)
# Numbers in Puppet are often string-encoded which is troublesome ...
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code to deal with the fact that numbers are often string-encoded seems to have been removed? Will this work with numbers?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As long as it is passed as a String type it will work as it always has, that being said, with future parser it will fail if it is passed a Numeric type, but this was always going to be the case.

…cts and only worry if the object responds to upcase
@cyberious
Copy link
Contributor Author

@mhaskel docs added.

underscorgan pushed a commit that referenced this pull request Mar 2, 2015
Loosen the restrictions of upcase and allow for recursion of the objects...
@underscorgan underscorgan merged commit 6d07a6a into puppetlabs:master Mar 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants