> > I was also bitten by this during testing and it made the thought of > converting my code to 4.0 daunting.
The auto conversion also holds for the current parser, so I don't see how that's making anything different, or daunting. Essentially what it comes down to is input sanitisation. Up until a certain point in time there was no way to define that a value should be of a type. The language tried to be smart about it to work around the issue introducing a different scala of issues altogether. Now that you can do that with the future parser there's no need for magic tricks that try to be intelligent about it. If we get two strings, we compare them as strings, even though they might also make sense as exponent numbers. And if a user goes 0 == 'orange' please don't do interpret that as 0 == 'orange'.to_i as that would return true but raise a Type or Runtime error instead. If we want to fix this, now is pretty much the right moment to do it. Type juggling would need to become formally documented in the language spec, both the why and the how it does it so people can implement the same behaviour if they decide to write custom parsers/compilers. Once something as fundamental as this is in, it's going to be tough getting it out. As a module author I want a language with the least amount of surprises and this behaviour is mighty surprising. You probably won't quickly run into it but when you do it'll make your head spin and take you a while to figure out what's going on. As an ops person I want a predictable language where I can't accidentally subtract 0 from a potato and in return get spaghetti bolognese in my configuration file. Now as far as the automatic conversion goes, or as PHP quite aptly calls it "type juggling", kill it. I'm always the one to go "break all the things" but really, this time, please "break all the strings". On Saturday, 1 November 2014 02:22:36 UTC+1, henrik lindberg wrote: > > F.Zappa - excerpt from "The Torture Never Stops": > > "Flies all green and buzzin' > In the dungeon of despair > Who are all those people > That he's locked away down there > Are they crazy > Are they sainted > Are they zeros someone painted > That had never been explained > Since at first it was created > But a dungeon like a sin > Requires not much lockin' in > Of everything thats ever been" > > ( > http://www.metrolyrics.com/the-torture-never-stops-lyrics-frank-zappa.html > for full lyric) > > Somehow fitting, Halloween and all... for what I want to bring up. > > 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. > > This is not the only place where String to number conversion is a very > bad idea. Someone recently had problems with conversions in a case > where string comparison was wanted for version strings. > https://tickets.puppetlabs.com/browse/PUP-3333 has the details. > > With --parser future it is at least consistent. In 3x different > operators used different rules. Now <, >, <=, >=, ==, and != all share > the same behavior; they convert a string to numeric if both sides of the > expression are numeric or can be converted to numeric. > > The in operator has some additional rules (see the spec, but it uses > the same comparisons as for the regular operators). > > We fixed PUP-3602 by not converting strings that are floating point 0 > with exponential part and we also do not convert values that are > floating point infinite in Ruby (e.g. 4e999 and such). This is a crutch > though, and it is only a matter of time until someone stumbles over the > next SURPRISE ! > > 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). > > > 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. > > 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. > > # 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 > > -- > > Visit my Blog "Puppet on the Edge" > http://puppet-on-the-edge.blogspot.se/ > > -- 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/90dd2c78-dc28-4e9e-a525-e2c9fa0dd11e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
