> 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.
> 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.
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.
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.
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.
> 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.
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.
Comments
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.
> 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.
Indeed it is, but at least that liability is much more obvious and publicised.
> 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.
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.
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.
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.
> 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.
That is a bug that is more easily (and less dangerously) fixed by asking for bytes and then decoding them from latin-1.
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.