I thought hiera always returns strings? ie. $myvar = hiera('testvalue')
should return a string, and validate_re( $myvar, '[0-9]+' ) should work
just fine?
Regardless, this is inconsistent:
OK:
$var = 1000
validate_re( $var, '[0-9+]' )
FAIL:
$var2 = 2000 + 1
validate_re( $var2, '[0-9+]' )
In the first case, the number is cast as a string. In the second, it is not.
The inconsistency makes this a bug, IMHO.
R.
On 21 May 2014 18:19, Brian Mathis <brian.mat...@betteradmin.com> wrote:
> On Wed, May 21, 2014 at 4:29 AM, Felix Frank <
> felix.fr...@alumni.tu-berlin.de> wrote:
>
>> On 05/20/2014 07:16 PM, Brian Mathis wrote:
>> > This is a bug in validate_re(), even though there is a workaround.
>>
>> Arguably so.
>>
>> One could also argue, on the other hand, that regular expressions are
>> matched by *strings* and nothing else. Sure, we've been spoiled by bash
>> and perl which don't give damn and implicitly convert to string every
>> chance they get. But that isn't a universal truth. Point in fact
>>
>> irb(main):001:0> puts "it works!" if 5 =~ /[0-9]+/
>> => nil
>>
>> I agree that it *is* inconvenient to check for two cases "is numeric" or
>> "contains a number" when logically the former implies the latter. I also
>> think that implicit string conversion would be a beneficial feature for
>> validate_re. But it is not necessarily a bug.
>>
>> Cheers,
>> Felix
>>
>
>
> If validate_re() is only effective on strings, then, in a dynamically
> typed language such as ruby/puppet, it better make sure it's casting to a
> string inside the function. Forcing the use of quotes is a workaround for
> something that it should be doing and creates inconsistency in the
> interface. Forcing the user to be aware of the internals of the function
> in order to use it defeats the point of using functions.
>
> One of the big problems here is that sometimes it works and sometimes it
> doesn't for the same data, depending on where you got it and what you did
> with it, which is clearly a bug. I'm not sure how else you can define a
> bug other than "actual behavior does not match expected behavior", when the
> expectation is merely that the function performs in a predictable way.
>
>
> ❧ Brian Mathis
> @orev
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CALKwpEwaUwoCQGDTeN6ztLJKUXoTMfgnFpK%3D7xZbifjb5sk_nw%40mail.gmail.com<https://groups.google.com/d/msgid/puppet-users/CALKwpEwaUwoCQGDTeN6ztLJKUXoTMfgnFpK%3D7xZbifjb5sk_nw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAJGKfwCBtVtBtUezvzy42vuXas%2BWFs1W9jkC_VeLXo3GSZoY1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
