How can I change the comment symbol in Ruby? It is normally #, but I want it to be a different character.
You could modify the parser definition in the source code, compile it and run with your custom Ruby binary, modifying any gems you want to use to match your new comment scheme.
You could write some type of preprocessor script to modify your comments in rb files to temporary files then launch ruby on those processed files.
Or you could deal with using #.
Propose your language change on the Ruby bug tracker, including:
Present a really strong use case, why you want to break 10s of millions of lines of existing code written by 10s of thousands of developers.
Create a proof-of-concept implementation for YARV, and ideally for the other implementations as well.
(Ideally) Create an automated migration tool.
Gather community consensus and support, respond to all questions and doubts.
Iff your proposal gets accepted, there needs to be a transition plan. It will probably look something like this:
When Ruby 2.4/3.0 gets released in December 2016, a deprecation notice will be added to the documentation.
When Ruby 2.5/3.1/4.0 gets released in December 2017, a warning will be added about the upcoming deprecation of #.
When Ruby 2.6/3.2/4.1/5.0 gets released in December 2018, a switch will be added that allows you to choose between # and your proposal, with the default being #.
When Ruby 2.7/3.3/4.2/5.1/6.0 gets released in December 2019, the default for the switch will be reversed.
When Ruby 2.8/3.4/4.3/5.2/6.1/7.0 gets released in December 2020, the switch will be removed, and your proposal will be the new comment character for Ruby.
Adoption of that version will probably be very slow, because of the massive backwards incompatibility your proposal induces, similar to Ruby 1.9 which took years to get adopted.
So, it's a lot of work for you, but sometime in 2021–2022, the Ruby community will have changed over to your proposal.
Related
I have Ruby code that uses "keyword arguments" like so:
def run_cmd(command, arg1: true, arg2: nil)
...
end
When I run the code, it works as expected, but my IDE doesn't seem to know how to interpret this. It renders the formatting of my entire file incorrectly because of these keyword arguments. Are keyword arguments not supported by Eclipse's Dynamic Languages Toolkit? (I'm using DLTK version 2.0.0) If not, is there a different Eclipse plug-in I should be using for Ruby?
You don't even need to know anything about Ruby or DLTK to answer this question, just common sense is enough:
Keyword arguments were added in Ruby 2.0, which was released in honor of Ruby's 20th anniversary on February, 24th 2013. Eclipse DLTK 2.0.0 was released on June, 24th 2010, over ten years ago and almost three years before Ruby 2.0.
So, by the simple laws of phyics and some common sense, it is immediately clear that DLTK 2.0.0 cannot possibly support Ruby 2.0 keyword arguments, because they simply did not exist back then.
As a general rule, you should expect some breakage and limitations when using ten year old IDEs.
Is anyone aware of how to retrieve the exact version (major, minor, patch) that a specific feature was added/removed/altered to the Ruby language?
Obviously one could comb through the history to find out, which is not ideal, and can be cumbersome to navigate. Was curious if anyone might know a better way to do it, as the documentation doesn't state when a method, class, etc. was added.
When documenting my own gems with YARD, it is easy to just add a #since tag to clearly show when something was added, but the Ruby API doesn't seem to have any such mechanism in its own documentation.
When writing gems, it is obviously handy to know such details when managing dependencies, and I was hoping there was a simpler solution, such as simply typing a method name into a website, and seeing the exact version it was added.
To clarify, basically a "changelog" for any item. For example, type in method name, see log of when it was added, changed, deprecated, removed, etc.
A prime example would be something akin to .NET Core's Reverse Package Search.
I was just doing this, unfortunately my answer is what you were hoping to avoid.
I was looking through history, but able to use GitHub's handy Blame feature to help track down when a specific line was edited. With this I could open the file in question click "Blame" and see when it was last edited/created.
Was a great way to track down when Exception2MessageMapper was added to the standard library. It was 17 years ago, as part of v1.4.0:
https://github.com/ruby/ruby/blame/trunk/lib/e2mmap.rb#L55
If a project passes the tests in Ruby 2.0.0-p648 and Ruby 2.3.1, does it make sense to also test with versions such as 2.1.8 and 2.2.3?
Has there been any language features that worked in Ruby 2.0 and Ruby 2.3 but were temporarily not working or worked differently in for example Ruby 2.2?
You should test your code for environments you intend it to be used in. Ruby language version is one thing that can vary. You might also consider testing against JRuby and Rubinius if your code is supposed to support it - e.g. it is provided as a public gem.
Logically, testing on earliest and latest versions should cover most failure scenarios with respect to language features (although not necessarily all language bugs since new ones can be introduced). As far as I know there has not been a Ruby feature that was deliberately added or removed in one version and then that decision reversed in a later version. Unless: Perhaps in your production code you are detecting a feature's existence and then using the feature in full - in which case an intermediate Ruby version which has the feature but not in its latest state could fail.
There may be other caveats too, and philosophically speaking when you start testing you want to avoid too much logical "this should work because . . ." thinking. The point of testing is to demonstrate that your code doesn't fail in ways you have covered (well, there's more depth to it than that, but the answer would get far too long if it dove into test philosophies). If you want to declare "works in all versions of Ruby MRI from 2.0.0 to 2.3.1" then you will feel safer making that statement if you have actually tested it. In fact when making such a statement in a public place, I would usually just say something closer to raw fact - "tested in versions 2.0.0, 2.1.4 and 2.3.1".
Obviously there are diminishing returns. If you have no problem in 2.1.9, it is very unlikely you will have a problem in 2.1.10 - at some point it will cost you more to check every minor variation, even just to look at the test results, than the benefit of extra coverage.
The usual answer to this problem is to test as many variations as your automated test environment can handle and you can be bothered to set up and maintain. If using multiple versions of Ruby is done for you in parallel by your test service provider - e.g. you are using Travis - then it is relatively cheap to test multiple versions. So you may as well get as much coverage on environment variations that you expect to see "in the wild" as you can be bothered to look at.
I want to ask about naming convention of ruby version.
According to this quesion ruby follows Semantic Versioning, but I could not find about x.x.x-dev and x.x.x-preview syntax in the document.
I think dev comes first and then preview, and at last rc comes up.
Do you know where is the ruby official document that explains about their versioning convention?
I'm not sure this is documented somewhere, however these are the most common conventions used in the Ruby core development
dev means the development version. It's the first stage, no public release. Normally you can download a night build or snapshot
preview is also what other projects normally call beta release.
rc is the release candidate, very close to the release
finally, you have the stable release
In Ruby Core, a new literal notation "foo"f for frozen strings have been proposed for Ruby 2.1, but now people are concerned that code written in such syntax would not be parsable by Ruby 2.0. Why is that an issue? Hasn't Ruby tried to be only backward compatible? That is, if code written in Ruby 2.0 can be parsed by Ruby 2.1 interpreter, isn't that enough? Why does code written in Ruby 2.1 have to be parsable by Ruby 2.0 interpreter?
That's a very good question. I have followed the core ML for a while and I believe the main concern here is that the new frozen literal syntax is a syntax change, not only a feature change.
Let me expand the answer a little bit. First of all, let's remember that we are talking about a minor version change, that is not supposed to break compatibility with previous code. Indeed, you may argue that in fact, this is not going to happen at all. Ruby 2.0 code will just work fine in Ruby 2.1, but not the opposite.
You also mentioned that is implicit that a new version will possibly include features not available in the previous version. But I believe here's exactly where the concerns are starting.
The new syntax is introducing not only a feature change but also a syntax change. It means that if you try to feed Ruby 2.0 parser with Ruby 2.1 code, it will possibly fail. And this may not be a good idea, for all the reasons we already know (compatibility, migration, maintenance, etc).
And this is quite different than when you create a new method in Ruby 2.1 that is not available to Ruby 2.0. In this case, it's true that 2.1 will have more features than 2.0, but if you feed the previous interpreter with the same code base, it will not complain. You didn't change the language syntax, you just enriched the core library. And, in this case, it's very easy to make your 2.0 code more similar to 2.1: just implement the missing methods.
This is not possible with a syntax change because you will need to reimplement the parser.
If you look at the Ruby changes under this point of you, you will see that a very few syntax changes were introduced between minor versions.
Changes like the stubby lambda, keyword arguments, new hash notation, they were all introduced with a major bump.
Generally speaking, syntax level changes may cause more maintenance issues compared to feature level changes. This is my interpretation of the reason behind the new frozen literal syntax and the reason why they ended up using .freeze instead of the new syntax. freeze already exists in previous Ruby version, but even if they would come with a completely new method, methods are not evaluated at parse time and they can be easily backported.
The answers I have in mind are:
easier migration from ruby 2.0 to 2.1
share code between ruby version
people seem to find the f-suffix ugly/confusing
Migration
When the syntax is parse-able by both ruby versions, it is one task less on the list to migrate from 2.0 to 2.1. Existing code may benefit from better frozen string handling without any changes.
Shared code between ruby versions
With a similar syntax, you can write ruby code (especially libraries), which work with multiple ruby version (2.0 and 2.1). This gives library developers a greater audience (and less versions to maintain for different ruby versions). The library user, however, has an easier time migrating from ruby 2.0 to 2.1. Still the ruby 2.1 version can benefit from better frozen string handling.
Personal taste
Reading through the ruby bug tracker, I see that some people seem to find the new syntax ugly/confusing. Here are some examples:
"[not using the f-suffix] looks like Ruby"
"The [f-suffix] notation is ugly."
"it is confusing about the character 'f'. For example, it remind 'Float'"
"I personally dislike prefix/suffix forms, they feel like u'str' in python"
"it looks very strange" (ok, this one is not from the tracker)
There are other people who like the new syntax. Well, this is subjective, but we are wondering why people complain, so it is a point :)