I was also bitten by this during testing and it made the thought of converting my code to 4.0 daunting.
So, I am very much not a fan of automatic String to Number conversion. Thanks, Trevor On Sat, Nov 1, 2014 at 11:39 AM, Kylo Ginsberg <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/puppet-dev/CALsUZFGqmf5D5eWCrkMvjH5sKx8X3OFtk6uPvNz_OHycb4ktEg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoU_BgcNz75ApQXGRMW30KP%3D-wXyCRKeyJ865cbqN77Vgg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
