user = { name: "Alice", age: 30 }
puts user[:name] # Alice
puts user["name"] # nil
I'm 100% convinced that every Ruby developer has at least once made a bug where they tried to access a hash entry using a symbol, where the key was actually a string or vice-versa.
It would be great if Ruby would finally have immutable strings by default and, at that point, it would be possible to make symbols be strings.
This would prevent any such user[:name] vs user["name"] bugs while not breaking any other functionality. And also keeping the memory "optimized" by reusing a single immutable string.
> I'm 100% convinced that every Ruby developer has at least once made a bug where they tried to access a hash entry using a symbol, where the key was actually a string or vice-versa.
Yeah, that is true. It adds a cognitive load onto the ruby developer writing the code as well. Personally I prefer symbols as keys in a Hash, mostly because I like symbols, I assume it may be faster usually (this depends on factors, such as how many symbols one uses, the garbage collection kicking off and so forth, but by and large I think for most use cases, Symbols are simply more efficient). We also have abominations such as HashWithIndifferentAccess; Jeremy wrote an article why that is not good (indirectly, e. g. the article he wrote was about Symbols more, their use cases and differences to Strings, but from this it follows that HashWithIndifferentAccess is not a good idea. While I agree, I think some people simply don't want to have to care either way).
If I need to query a hash often, I tend to write a method, and the method then makes sure any input is either a string or a symbol for that given Hash.
> It would be great if Ruby would finally have immutable strings by default
But it has. I still use "# frozen_string_literal: true", but if you omit it, the Strings are frozen by default. People could set "# frozen_string_literal: true" in a .rb file if they want to retain the old behaviour.
> it would be possible to make symbols be strings.
But Symbols are not Strings. And bugs based on x[:foo] versus x['foo'] are always going to happen. They are very easy to avoid though. I don't really run into these in my own code, largely because I settled on symbols as keys for a Hash.
> And also keeping the memory "optimized" by reusing a single immutable string.
But a Symbol is not a String. Not even an immutable String. I understand what you mean (and internally it may be that way already, actually), but it is not a String.
I also prefer symbols as keys in hash. It just looks more aesthetically pleasing. :)
I think the optimization string vs symbol is negligent in most of the apps. If you need that level of optimization, you should probably switch to Rust.
> If I need to query a hash often, I tend to write a method, and the method then makes sure any input is either a string or a symbol for that given Hash.
This is terrible. This is the exact opposite of what Ruby is trying to achieve: developer happiness. You basically implement "symbol is a string" for hashes (aka HashWithIndifferentAccess).
> But it has. I still use "# frozen_string_literal: true", but if you omit it, the Strings are frozen by default.
This is not the case. If you omit "# frozen_string_literal: true", the strings are mutable, in all versions of Ruby, even in Ruby 4.0, which will be released on 25 Dec.
> But a Symbol is not a String. Not even an immutable String. I understand what you mean (and internally it may be that way already, actually), but it is not a String.
If it walks like a duck and quacks like a duck...
Who cares? What's the difference it makes for you whether symbols and string are interchangeable? Show me one valid use-case where having symbols and strings being different (user[:name] vs user["name"], or attr_reader "name") is useful.
Rails makes this more confusing with HashWithIndifferentAccess[1]. People coming from Rails are often confused by this when working with straight ruby and this kind of hash access doesn’t work.
Agreed. However had it should also be mentioned that this originated from rails.
Many bad things originate from the rails ecosystem. (Arguably some good too, but I am very pessimistic ever since shopify's recent powermove and DHH side-line commenting off-the-fence while being on shopify's board.)
No one thinks they are a dick. But you are. At least in many instances as many of the comments here and elsewhere point out. I had similar experience trying to start a discussion about something in one of the Homebrew repositories.
The fact that you have many friends who confirm your bias of not being a dick...means exactly nothing. You have people telling you your words made them perceive your comment as being arrogant/blunt and your reply is: I'm successful open-source maintainer and have many friends who think I'm not arrogant and I only take critique from them. Have it your way. But in my eyes, you're being a dick. (Don't misinterpret this as my judgement of your engineering skills. I love Homebrew and it's an incredible feat. Congrats.)
If you love Homebrew, maybe you might want to consider if repeatedly calling me a dick or arrogant/blunt is a particularly nice way to treat someone who spends their spare time building software you rely on.
This, this is being a dick. Holding your project hostage because you want to flex your power over someone. It's entitled behavior. Glad I moved to MacPorts years ago.
The variable naming convention used here could be improved for clarity. I prefer appending `El` to variables that hold DOM elements, as it makes identifiers like `tableEl` clearer and helps avoid ambiguity between variables such as `table` and `row`. Also, the variable named `table` does _not_ actually represent a table element; it would be more accurate to name it `data` or `tableData` to better reflect its purpose.
Probably because I first learned programming with JavaScript and very early started using jQuery, but I've always used prefixed `$` to indicate "This is a DOM element" (started doing this once jQuery stopped being so popular). So the example would be something like this for me:
let table = [
['one','two','three'],
['four','five','six']
];
let $body = document.body;
let $table = document.createElement('table');
$body.appendChild($table);
Always felt it worked out short and sweet, and as long as you're not refactoring a jQuery codebase, seems to work out well in practice.
You're right! Although I get faily far by using Bust-a-gem VS Code extension. (The underlying ripper-tags gem can work with any IDE)
https://github.com/gurgeous/bust-a-gem
I have an "on save" hook that runs ripper-tags on every file save. This keeps the definitions always up to date.
This sounds like a really innovative idea. I haven't seen a dedicated place for "collection of useful procs", but one emerging pattern is to use `app/services` and then have a bunch of single-responsibility service classes that each have call or perform method and then you use the service when you need some shared functionality. It's like a proc, but instead it's a class with `#call` method.
It's weird, and different and therefore a bit repulsive (at least to me it was) at first. But, once you learn it, it's so easy to read it and to understand what's going on.*
* Side-note: Sometimes variables or methods look the same as parenthesis () are optional. So, yes, there's more things that can look like magic or be interpreted in multiple ways, but more times than not, it helps to understand the code faster, because `clients` and `clients()` (variable or method) doesn't matter if all it does is "get clients" and you just need to assume what's stored/returned from that expression. Also "get clients" can be easily memoized in the method implementation so it gets as close as possible to being an actual variable.
Oh, I didn't know that André wants to sell gem.coop and/or rv. Can you please point me to more info about where this intention to sell gem.coop and/or rv was mentioned?
They want to sell some RubyGems logs about corporations (not individuals) using RubyGems API, to...Ruby Central?
As André explained on his site, he was on-call at the time when they were removing him. He acted to protect the service by limiting access. No harmful actions done by him were ever discovered by Ruby Central. It's two entities fighting to remove the other. You can say Ruby Central was right, I can say André was right. But we do know that Ruby Central fired the first shot when they (could've been an actual hacker) removed literally everyone from RubyGems and Bundler projects.
First of all, thank you! It's unbelievable that you built the first version of `gem install` in a single night. It must have been an amazing feeling. I remember the drive when I was doing some hackathon with a few friends. It's the best feeling a software engineer can have.
When you left RubyGems and Bundler (let's call them "Projects") team, you handed over your authority to whoever was left and/or was added later. It doesn't matter in which order things happened. What matters is that Ruby Central _and the rest of the team_ were the stewards of Projects. The important part here being _and the rest of the team_. André had every right to keep being part of that team, and he was for a long time, together with many other team members, all of which were removed by "a representative from Ruby Central". What an inhuman way to remove someone from a Project. "Hire" someone to do the dirty job for you so you don't have to.
The decisions in a team should be done by reaching a team consensus. Not by one actor.
I believe it's for the better that André was removed from the team, but it shouldn't have been done like this. Ruby Central lost their trust in the eyes of many. They could've achieved the same goal in a much better way.
How can I trust an organization with management of something if they failed to manage this whole situation? Claiming this is all in the name of security and then not even knowing how to properly remove access from someone. So much about security...
> Symbols aren’t interchangeable though.
I'm 100% convinced that every Ruby developer has at least once made a bug where they tried to access a hash entry using a symbol, where the key was actually a string or vice-versa.It would be great if Ruby would finally have immutable strings by default and, at that point, it would be possible to make symbols be strings. This would prevent any such user[:name] vs user["name"] bugs while not breaking any other functionality. And also keeping the memory "optimized" by reusing a single immutable string.