3 ms·

I read parent’s “bonkers” in a positive way. Then for instance most languages get away with inline optional typing by using “:” , for instance “ping_user(name:

by hrktb 6y ago

I read parent’s “bonkers” in a positive way. Then for instance most languages get away with inline optional typing by using “:” , for instance “ping_user(name: String)“. In ruby it’s of course already taken, in no small part because there are 3 or 4 different ways to declare hash parameters. I’d imagine most decent syntax candidates had similar issues, due to ruby’s syntax versatility.

Polylactic_acid 6y ago
The worst part of ruby imo is the fact that a hash can have both string and symbol keys. Countless times I have encountered issues where a function takes an options hash and the callers use both string and symbols for the same key depending on which caller it is. I end up calling the function to convert to symbols all the time.
- rudolph9 6y ago
  Actually, if my memory serves me, a ruby hash can use any object a key! And considering everything in ruby is an object (even the class `Object`) it’s really quite elegant
  - vlunkr 6y ago
    This seems to be getting downvotes? I don't know why, it's accurate. Anything can be a key in Ruby.
- tdeck 6y ago
  This is why ActiveSupport (Rails) has Hash#with_indifferent_access and people use it all over the place.
Glyptodon 6y ago
I'm trying to think of any typical chars that don't already mean something and I think at best you'd have to use a pair and even then it would potentially break older code. Very badly offhand something like: `attr_accessor ~:String :name` and `def sing(~:Song song):` seems pretty ugly but borderline feasible on the premise that while ~ and : have meaning in Ruby, it's not super likely that bitwise inverting symbols is common. (I'm sure there more reasons that wouldn't work or isn't great.) I don't like the separate file thing, but it does seem more challenging than I'd have thought to avoid. I guess on a tangent Ruby code historically cares a lot more for duck typing so strong typing will be a headache for a lot of stuff.
regularfry 6y ago
I genuinely think that adding `:` as a hash separator was a mistake. Apart from anything else, you get this weird effect where the type of the key in `{"foo": bar}` isn't what you think it is.

by hrktb 6y ago

Polylactic_acid 6y ago

The worst part of ruby imo is the fact that a hash can have both string and symbol keys. Countless times I have encountered issues where a function takes an options hash and the callers use both string and symbols for the same key depending on which caller it is. I end up calling the function to convert to symbols all the time.

rudolph9 6y ago
Actually, if my memory serves me, a ruby hash can use any object a key! And considering everything in ruby is an object (even the class `Object`) it’s really quite elegant
- vlunkr 6y ago
  This seems to be getting downvotes? I don't know why, it's accurate. Anything can be a key in Ruby.
tdeck 6y ago
This is why ActiveSupport (Rails) has Hash#with_indifferent_access and people use it all over the place.

Glyptodon 6y ago

I'm trying to think of any typical chars that don't already mean something and I think at best you'd have to use a pair and even then it would potentially break older code. Very badly offhand something like: `attr_accessor ~:String :name` and `def sing(~:Song song):` seems pretty ugly but borderline feasible on the premise that while ~ and : have meaning in Ruby, it's not super likely that bitwise inverting symbols is common. (I'm sure there more reasons that wouldn't work or isn't great.) I don't like the separate file thing, but it does seem more challenging than I'd have thought to avoid. I guess on a tangent Ruby code historically cares a lot more for duck typing so strong typing will be a headache for a lot of stuff.

regularfry 6y ago

I genuinely think that adding `:` as a hash separator was a mistake. Apart from anything else, you get this weird effect where the type of the key in `{"foo": bar}` isn't what you think it is.