On Sat, Nov 1, 2014 at 3:35 AM, David Schmitt <da...@dasz.at> 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 puppet-dev+unsubscr...@googlegroups.com.
> 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 | k...@puppetlabs.com | 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 puppet-dev+unsubscr...@googlegroups.com.
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.
