5 ms·

> You can change the encoding of a string. Just jesus christ wow. erm, wat? Edit: To refute some of the points: > Why on earth does defined? return a string

• lucian1900 14y ago
  Changing the encoding of a string effectively destroys the data inside. It's entirely useless and potentially very dangerous. Block-based loops in Ruby are pretty nice, but the semantics could be simpler. Rust gets this right. Hashable mutable objects are a giant liability. Ruby even has freezing of objects, so it should only allow hashing frozen objects at least. Ignoring scope by default is extremely stupid and dangerous. Namespacing is pointless if it's off by default.
  • xentronium 14y ago
    > Hashable mutable objects are a giant liability. Ruby even has freezing of objects, so it should only allow hashing frozen objects at least. Well, of all dangerous things you can do with ruby, this is one of the least dangerous ones. How about "any gem can monkey patch any other gem or even core classes"? Isn't this a giant liability? Besides, it's not that difficult to make your custom hash that only allows immutable objects for keys.
    • lucian1900 14y ago
      Indeed it is, but at least that liability is much more obvious and publicised.
  • riffraff 14y ago
    > Changing the encoding of a string effectively destroys the data inside. You are assuming the string had the right pair of <encoding type, byte value> which is not guaranteed. For example, an old mysql binding wouldn't handle some of the encoding settings correctly, so you'd get a UTF-8 string with attached data in latin-something. This could be trivially fixed in client code by simply calling #force_encoding.
    • lucian1900 14y ago
      That is a bug that is more easily (and less dangerously) fixed by asking for bytes and then decoding them from latin-1.
      • stouset 14y ago
        And yet, in 99.5% of use-cases, it's infinitely more convenient not to have to jump through that hoop. I've been a Ruby developer for… seven years now, and have literally never encountered actual problems in the real world by this, by mutable hash keys, or well over half the other issues on this list. And I'm willing to bet the vast majority of other developers haven't either. Ruby has mostly sensible defaults that work as expected in most practical cases.
  • vidarh 14y ago
    > Changing the encoding of a string effectively destroys the data inside. It's entirely useless and potentially very dangerous. Says you. For my part, I've more than once had to deal with data that the source tells me is in one encoding, but where I can't trust the encoding and have to use heuristics to determine whether or not to switch encoding after I've read the string in. Yes, there are other ways of handling that than changing the encoding, but that doesn't mean it isn't convenient to be able to correct the encoding value already attached to the string. As for the "potentially very dangerous" I don't really buy that. Yes, you can turn the string into complete gibberish if you call it without knowing what you're doing, but it's not exactly something that you're likely to call by accident.
    • lucian1900 14y ago
      If you don't know (or trust) the encoding, you have bytes, on which you can do whatever heuristics you wish, then decode into a string. It's much safer than changing the encoding on an existing string.
      • vidarh 14y ago
        How in the world is it any different? #force_encoding is not meant to mutate the data. The entire point of it's existence is to be able to correct a wrongly set encoding.
        • lucian1900 14y ago
          If you don't know the correct encoding of a sequence of bytes, then you don't yet have a string, just a sequence of bytes. You can decode the bytes into a string, or encode a string using a particular encoding into bytes. Bytes != strings.
• masklinn 14y ago
  > Why not? Strings are perfectly valid in boolean context. That's not a good reason for anything, by that yardstick Array#length could return a float and nil#nil? could return an array. And worse, the `?` postfix in Ruby normally means the method returns an actual boolean, not a "boolean context" (convention over configuration only works if the convention is respected). You can't XOR a string and a boolean (no `^` defined on string, although XOR-ing a boolean and a string will work), you can XOR two booleans. > Why not? It is possible to shoot yourself in the leg, but otherwise a very useful feature. I'm not sure, but I think he phrased it badly and asks why "interpreter-provided" mutables (e.g. Array) can be set as hash key: while "user objects" are also hashable by default in Python, built-in collections and the like are specified as unhashable as the semantics are not really sensible: >>> {{}: 1} Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unhashable type: 'dict' >>> {set(): 1} Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unhashable type: 'set' versus irb(main):002:0> {[] => 1} => {[]=>1} irb(main):003:0> {{} => 1} => {{}=>1}
  • riffraff 14y ago
    because ruby does not have a separate tuple data type, so it's trivial to do so data[[v1, v2]] = something and because strings are mutable in ruby. If you couldn't use mutable objects as hash keys a bunch of things would become _way_ harder.
    • masklinn 14y ago
      > If you couldn't use mutable objects as hash keys a bunch of things would become _way_ harder. data[[v1, v2].freeze] = something meh. Hell, Hash could even freeze its parameters on entry if they're not already frozen. Meanwhile if anybody gets a hold of the key and happens to mutate it (not necessarily for nefarious purposes, just because it solves they problem) you can quite literally lose your pair: irb(main):001:0> h = {} => {} irb(main):002:0> l = [1, 2] => [1, 2] irb(main):003:0> h[l] = 1 => 1 irb(main):004:0> h[l] => 1 irb(main):005:0> l[1] = 3 => 3 irb(main):006:0> h[l] => nil irb(main):007:0> h[[1, 2]] => nil irb(main):009:0> h[[1, 3]] => nil irb(main):010:0> h => {[1, 3]=>1} irb(main):011:0> h[[1, 3]] = 3 => 3 irb(main):012:0> h => {[1, 3]=>1, [1, 3]=>3}
• viraptor 14y ago
  Most of the answers to your answers could be summarised with "principle of least surprise makes sense". That's why most/all methods ending with an "?" should return a boolean, mutable objects should warn/fail if used in context where immutable is expected, string encoding should not be possible to override, constants should be constant, things called threads should be threads... Otherwise things are not consistent and confusing. Yes, with enough time you just learn all the tricks and start fighting for the status quo, bacuase that's how things always worked and it's ok. But is it?...
• Karunamon 14y ago
  I always wondered about the defined? thing too. A rubyism is that any function suffixed with a ? should return a true/false, but then again, another rubyism is that everything that isn't explicitly False or nil evaluates to True, so it kind of works out. I can see how this would make anyone coming from another language kind of scratch their heads, though. You'd expect defined? to return simple boolean, not evaluate the type of object being referenced (kind of like .class)
  • Xylakant 14y ago
    No, your conception of methods suffixed with ? is false. Methods suffixed with ? are expected to return a truthy/falsy value. nil and false are perfectly falsy in comparisons and any string will evaluate to true. So returning the type of the object in question and nil in the false case is perfectly valid and expected. It's not the only method to work that way.
    • gfodor 14y ago
      As stated elsewhere in the thread, this is a clever retort but in practice defined? is the only major example I've seen where the ? suffix results in a non-boolean return value. You're arguing over a convention, and I think most people writing Ruby would be surprised to learn defined? returns a String.
      • Xylakant 14y ago
        It's a common misconception that ruby developers think that predicates must return a boolean value. It's still a misconception. This blog post linked elsewhere in the discussion is a good summary: http://blog.leshill.org/blog/2012/03/25/a-question-of-truth.html http://blog.leshill.org/blog/2012/03/25/a-question-of-truth.... Another notable example is nonzero? which returns the value of the number if nonzero and nil otherwise: jruby-1.6.8 :097 > 1.nonzero? => 1 jruby-1.6.8 :098 > 0.nonzero? => nil See also File#world_writable? [1], File#world_readable? [2], File#size? [3], Kernel#autoload? [4], Encoding#compatible? [5] If you rely on predicates always returning true/false you're in for a nasty surprise. [1] http://ruby-doc.org/core-1.9.3/File.html#method-c-world_writable-3F [2] http://ruby-doc.org/core-1.9.3/FileTest.html#method-i-world_readable-3F [3] http://ruby-doc.org/core-1.9.3/File.html#method-c-size-3F [4] http://ruby-doc.org/core-1.9.3/Kernel.html#method-i-autoload-3F [5] http://ruby-doc.org/core-1.9.3/Encoding.html#method-c-compatible-3F
• draegtun 14y ago
  >>Setting `$=` to something truthy causes all string operations to become case-insensitive. This and other magic globals from perl are mind blowing. >Perlisms. They're incomplete Perlisms that's the real flaw because in perl these special variables are dynamically scoped. NB. $= does something completely different in perl. I don't know of any perl special variable that replicates what Ruby's $= does.