-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dont echo assignment expressions #12
Conversation
I think this is a really awesome idea. |
@hsbt Is this a better implementation than #11 ? I guessed on what the new configuration setting should be called ( I also wrote it so that the echoing isn't suppressed when running ruby < 2.6.0 because Could we do something like not require the |
Anything under |
@eregon Thanks for the tip about Ripper. Just updated the patch to use Ripper instead and removed the restriction for 2.6.0. |
@onlynone Can you add test for this change? |
Tests added. |
For
Opinions? |
@stomar it sounds like you'd want to set
or
or just type
|
Would it be better if the default for |
@nobu just checking in to see if there's anything else that can be done. |
Seems @aycabta working on the overhaul of irb now, stay tuned plz. |
Didn't @k0kubun just commit a bunch of stuff? Also, it looks like a lot of that came from ruby/ruby. Should I be making a PR there first? |
eba26ac
to
8ce9ce7
Compare
8ce9ce7
to
0a3a0f5
Compare
Failing test was actually related... fixed and squashed all commits. |
OK, I understand the Ripper's maintenance condition.
Hi! As a newbie on ruby on rails I feel that something has gone seriously wrong here. I have just searched the Internet, asked in forum for 24 hours, before finding the reason that irb does not echo the object I am creating, while following guides on learning Rails. After testing if this new behavior was caused by the switch from bash to zsh (on Mac), my rails configuration and so on, I finally got an answer on the Rails forum that from version 2.7, Ruby no longer echoes the return value when creating and assigning a new object. I also learned from another user that there is a configuration file for irb. And finally I found the source for this new behavior on this github page. As you might expect I do not like this change. For me, who is just learning both Ruby and Rails at the same time, I really appreciated the old behavior, when irb echoed the return value when I create a new object. "Would it be better if the default for echo_on_assignment was true so that no behavior changes unless one explicitly sets IRB.conf[:ECHO_ON_ASSIGNMENT] = false or uses --noecho-on-assignment ? I certainly prefer to suppress the echo of assignment expressions, but I can understand if we don't want behavior to change by default." Spot on! As a newbie I can't argue against this new feature (from what I read you want Ruby more like Python-like, not echoing out hundreds of lines of code). My argument for letting the default value be But for a developer proficient in Ruby irritated over lines of echoed code, it would probably easy to change the behavior to So for me this is a pedagogical question. What should be the default behavior? And how will it effect the users? A new user just learning ruby? An experienced programmer? Please set the default value back to true! So you restore the previous behavior and help all new users that are learning Ruby (or Rails). If any user in time want to change the behavior of irb down the road, that person are experienced and most likely also know how to change these settings. |
It's spelled "newbie". https://www.merriam-webster.com/dictionary/newbie |
@gdonald Thank you Greg for correcting my spelling. |
If seeing the value from the return of a function is valuable, you don't have to look under the hood of irb settings to see it. You can just type the name of the variable you assigned the value at the prompt after the function call. This change only comes into effect when you're doing an assignment like |
Yes, I discovered that calls to the object echoed the value within minutes. The problem was that this behavior did not match the online guide I was following. This is a new behavior in Ruby from version 2.7. You have therefore, without warning, changed a behavior that has existed for many, many years. Of course, it can be argued that this changed behavior, in time, will be reflected in guides when they are being updated. I would like to argue that this change was not asked for. If I read the original case (#11) there was a requested for a setting to be able to turn off the echo for assignments. That request is fulfilled by changing the configuration But instead of fulfilling that original request, you have changed a default behavior, so that all users of Ruby/Rails are affected by this new default value. I did not understand that there was such a request? If there is a general and strong desire to change this default setting in the ruby community, I must have missed it. If you can show that there is a strong request for this change of the default behavior, I will have to accept this change. Another aspect of this is consistency. An important mantra for Rails is "Sensible defaults". Due to the changes in Ruby, we now get an incomprehensible and inconsistent behavior in the IRB. Previously, the rule was that you always got a return value echoed. Now we have a situation where calling a variable echo the value. When calling “new “, you do not get an echo of the return value. But If you call destroy, you get an echo of the return value in irb. Again, I argue that as an experienced developer you can easily change these settings to your liking. But not so easy for the one who is just learning Rails. New developers will not know that they can change this behavior in a setting. As it now stands, this change doesn’t seem to be documented at all. So instead of fulfilling the original request (to be able to turn off the default behavior), you have changed the general behavior for all users of Ruby/Ralls. |
Please change the default back to what it has (always?) been. This behaviour change is totally unexpected and irritating, and I'm saying this as a longtime Rubyist. In Ruby, everything evaluates to something. Till now, the philosophy of IRB adhered exactly to that idea. Hiding the value of an assignment is not POLS. |
I changed the behavior by #129.
And I released irb gem 1.2.6 now. Please try it by |
I created a concise Pull Request #130. (ref. #129 (comment))
And released 1.2.7. |
Same idea as #11 but it uses
RubyVM::AbstractSyntaxTree
ripper
rather than theparser
gem.It would be nice to have a solution that's back-portable to ruby versions prior to 2.6 though.I'm open to any ideas.