On Sat, Nov 1, 2014 at 3:35 AM, David Schmitt <[email protected]> wrote:
> On 2014-11-01 01:22, Henrik Lindberg wrote:
>
>> Somehow fitting, Halloween and all... for what I want to bring up.
>>
>
> Indeed. Cross type interactions are the worst.
>
> Yet again someone was bit by the automatic String to Numeric conversion
>> that is in Puppet (and also in --parser future).
>>
>> The particular thing this time was
>> https://tickets.puppetlabs.com/browse/PUP-3602 that caused certain md5
>> fingerprints to look like floating point values of value 0 (they all
>> started with "0e" but had different digits after the e, and since 0 * 10
>> ^something is always 0 the two different md5 fingerprints were reported
>> to being equal.
>>
>
> Wow.
>
> The best cure is naturally to never do String to numeric conversion. And
>> we wonder what people feel about that. Should we go for this in Puppet
>> 4.0.0 (and have a 3.7.4 release as the last of the 3x series where this
>> behavior is implemented when using --parser future).
>>
>
> thirce yes!
>
+1. The less magic the better!
>
>
> The requirement to compare strings and numerals can also be implemented by
> converting the numeral to a string (using a canoical non-locale dependent
> format). This produces a much safer route, as creating a string has less
> degrees of freedom.
>
> There has also been a number of other suggestions how to fix this, that
>> are less appealing, and for the sake of not having to waste anyone's
>> time, here they are, with the reasons why they are not so appealing.
>>
>> * Only convert if LHS is a Number. This makes the order of the
>> comparison matter and then ($x == $y) != ($y == $x) which is really bad.
>>
>> * Add === operator to compare both type and value. This is a slippery
>> slope since we probably want Integer and Float to compare equal - say
>> 0.0 and 0. It adds yet another operator, and we have to decide what
>> case, selector and in should use since there is no way to specify if one
>> or the other should be used.
>>
>
> I'd not call that a slope, that's a cliff. See how PHP and javascript
> struggle with this.
>
> Instead, since we already have sprintf for value to string conversion,
>> and there is a scanf in Ruby which does the conversion the other way, we
>> can simply add that function to core puppet for value conversion.
>>
>> We could also add to_number(s), or to_number(s, format_string).
>> When doing that though, we risk ending up with a plethora of to_xxx
>> functions, and we could instead offer one more universal
>> convert_to(Type, value, options) function e.g.
>>
>
> Regardless of how you implement it, a good conversion function must be
> *strict*. things like "3 Apples" (or md5 hashes) cannot safely be converted
> into a number, even if some functions valiantly try.
Agreed.
Re the many to_x functions vs one convert_to function, I lean toward the
former approach because it's more aligned with the "do one thing well"
design principle. Otoh I fear the single convert_to approach could end up
harboring some odd corner cases and/or ambiguities (should a string of
comma-delimited numbers convert to an array of Numbers?), which could be
obviated by the clear, simple contracts of individual to_foo functions.
Kylo
>
>
>
>> # best effort, or fail
>> convert_to(Number, value)
>>
>> # only if it is an integer, or fail
>> convert_to(Integer, value, {base => 10})
>>
>> # convert integer to hex string with some extra text (the sprintf way)
>> convert_to(String, value, {format => "Hex %x"})
>>
>> # convert to array of string (give full control over all
>> # nested conversions.
>> #
>> convert_to(Array[String], value, {
>> Integer => { format => "0x%x" },
>> Float => { format => "%#.4G" }})
>>
>> # etc.
>>
>> So - "Boldly break all the (s)t(r)hings"?
>>
>> - henrik
>>
>>
>
> --
> * Always looking for people I can help with awesome projects *
> G+: https://plus.google.com/+DavidSchmitt
> Blog: http://club.black.co.at/log/
> LinkedIn: http://at.linkedin.com/in/davidschmitt
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/puppet-dev/5454B78C.5030202%40dasz.at.
>
> For more options, visit https://groups.google.com/d/optout.
>
--
Kylo Ginsberg | [email protected] | irc: kylo | twitter: @kylog
*Join us at **PuppetConf 2015, October 5-9 in Portland, OR - *
http://2015.puppetconf.com.
*Register early to save 40%!*
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CALsUZFGqmf5D5eWCrkMvjH5sKx8X3OFtk6uPvNz_OHycb4ktEg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
