I came across this project the other day and thought it was an interesting way to augment learning and using Ruby.
Suggest gives objects two extra methods; what_returns? and what_mutates?. Both methods take a result that you are interested in and return the methods you could call on the object to get that result.
For example:
require 'suggest'
[1,2,3].what_returns? 1
=> [:first, :min]
I can see this being useful when you're tooling about in irb and you're sure that there is a method that does the thing you want but you can't remember it. It could save a trip to search the docs and could even suggest better methods than the one you were thinking of.
Check it out on GitHub:
jbodah
/
suggest_rb
❓ tells you which method does the thing you want to do
Suggest
tells you which method does the thing you want to do
Disclaimer
I don't recommend you ship this in your Gemfile. Keep it in your system's gems (e.g. gem install) and load it as needed (e.g. irb -rsuggest, RUBY_OPT=-rsuggest irb, etc)
Installation
gem install suggest_rb
Usage
require 'suggest'
# Object#what_returns? tells you which method returns the value
[1,2,3].what_returns? 1
=> [:first, :min]
# You can also specify the args you want that method to take
[1,2,3].what_returns? [1], args: [1]
=> [:first, :take, :grep, :min]
# By default, it only returns methods that don't mutate the object
[1,2,3].what_returns? [1], args: [1], allow_mutation…
Top comments (11)
I agree this isn't exactly production-ready, and honestly it probably never will be. But it might be useful in a dev environment (not production, not test) as a handy wait-is-there-a-Ruby-way-to-do-this tool.
It actually reminds me a lot of similar tools for Smalltalk (see Avdi Grimm's overview of the power of the Pharo Smalltalk IDE) and could be similarly integrated into Ruby IDEs as an autosuggest tool.
Rather than freaking out because it's not production-ready, maybe let's remember this is a toy project and a neat development tool, and it could be quite handy day-to-day even if you shouldn't include it in your production environment.
I absolutely adore
Enumerable, but I don't remember everything it can do all the time. I don't feel guilty or inferior because of that. There's too much information in the world to remember all of it.I strongly suggest reading Don Norman's The Design of Everyday Things, specifically the chapter about knowledge in the head vs. knowledge in the world. The more we have to remember, the more mistakes we make. The more we need to rely on our memory to make tools available to us, the fewer tools we're likely to use in practice. This is how humans are.
I'd posit that the fewer details we have to remember in order to code, the more we can think about the bigger questions: What are the edge cases? What are the user needs, and is this code I'm writing actually fit for purpose? Will the next person editing this code be able to understand what I wrote, or should I break down the problem in a different way?
That's the kind of understanding and productivity I want in my team. I don't care whether my teammates know what
Enumerable#grep_vdoes without looking it up in the docs. I do care whether they know how to read a requirements document and ask clarifying questions. I do care whether they notice that a method or class is getting too big and feel the need to split it up. I do care whether they know to prioritize shipping features as a team over finishing a personal task list. There are so many things I care about more than their proficiency in Ruby (or other language) trivia.So... different strokes for different folks?
This is pretty harsh. I'd suggest that we both care that the team knows the language, but we define "knowing the language" differently. I think you can write clean, idiomatic, optimized Ruby without knowing all the details by heart, and in fact I believe you're more likely to do it through automated tooling than through memorization. You seem to disagree with some or all elements of that hypothesis. I hope your approach works for you.
Good chat everyone, I think this came to a nice conclusion. I think I agree mostly with Ariel and that is one of the reasons I found this project interesting. Not having to keep a bunch of methods in your head is much more fun and productive than memorising standard libraries.
Also, the experimental nature of the library itself definitely means that it wouldn't be entering the production group of gems in any codebase I am working on. As a tool that you could include in your
.irbrcor.pryrcand use when debugging/playing in the terminal, it could be useful.Ya, nice tool. But might not be useful when using a framework. Need to shift to IRB console and write the code there to see, will equally time consuming as searching on web.
But still I like the efforts
You'd be surprised how many times I open the
rails consoleduring development to test and mess with things. I think this could be used alongside that.Ya, you are right.
I agree. Really helpful on the go. I just installed it.
Many people benefit from RubyMine or from Ruby-aware plugins to IDEs like Vim or VSCode. This could be the beginning of great tools to help people figure out what code to write instead of getting stuck browsing Enumerable documentation. The less people have to remember to be productive, the better.
What's the negative value you perceive here?
Thanks for jumping in Josh! It's interesting to hear the motivation behind the project as well as how you've found using it over time too. I regularly find you start projects for one reason and a completely different use case emerges.
This is a really creative bit of functionality.