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

[cyberious]

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

[cyberious]

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]

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.

[elyscape]

Why the spacing changes here?

[cyberious]

IDE, generated white spaces

[elyscape]

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]

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

[elyscape]

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]

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

[underscorgan]

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

[cyberious]

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.

[cyberious]

@mhaskel docs added.