Skip to content
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

Fix compatibility with frozen-string-literal and newer rubies #80

Merged
merged 1 commit into from
Apr 15, 2024

Conversation

casperisfine
Copy link

Also setup CI

Fixes: #47

cc @jhawthorn, @pat.

Also @banister if you are looking for maintainers for this gem, let us know, as it would be a shame if it broke on a future Ruby version.

Also setup CI

Co-Authored-By: Pat Allan <pat@freelancing-gods.com>
@casperisfine
Copy link
Author

@casperisfine
Copy link
Author

👋 @kyrylo @rf- @ConradIrwin sorry for the cold ping, but could any of you review and hopefully cut a new release?

For context: https://twitter.com/banisterfiend/status/1779810797251895464

@@ -104,15 +104,15 @@ def extract_first_expression(lines, consume=0, &block)
# @param [Array<String>] lines
# @return [String]
def extract_last_comment(lines)
buffer = ""
buffer = +""
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the same as String.new("")?

In case it is, maybe we could use it instead? It's less cryptic IMO.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not quite the same. +@ only dup the string if it's not already mutable. String.new("") will always create a copy.

But it doesn't make a big difference, so I don't mind changing it. But then "".dup might be even more readable.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Provided +"" is valid Ruby going back several versions (which I think it is - and the CI runs should confirm that), then I personally would prefer keeping it. Yes, right now it's not common syntax, but taking a step towards normalising this in Ruby code feels smart to me - it creates a single mutable string, which is exactly what's required.

String.new("") and "".dup are, as @casperisfine has noted, both duplicating strings - yes, it's a small thing, but I feel like it's not the best habit to lean into from a performance perspective.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, thanks for the clarification. This is what I found:

https://github.com/fastruby/fast-ruby?tab=readme-ov-file#string

String#dup vs String#+ code

Note that String.new is not the same as the options compared, since it is always ASCII-8BIT encoded instead of the script encoding (usually UTF-8).

$ ruby -v code/string/dup-vs-unary-plus.rb
ruby 2.4.3p205 (2017-12-14 revision 61247) [x86_64-darwin17]

Calculating -------------------------------------
String#+@ 7.697M (± 1.4%) i/s - 38.634M in 5.020313s
String#dup 3.566M (± 1.0%) i/s - 17.860M in 5.008377s

Comparison:
String#+@: 7697108.3 i/s
String#dup: 3566485.7 i/s - 2.16x slower

Let's stick with +""

@kyrylo
Copy link
Collaborator

kyrylo commented Apr 15, 2024

This is looking good, @casperisfine, thank you for the PR!

I only have a minor question, and then this is good to be merged and released.

@kyrylo kyrylo merged commit 2d130a4 into banister:master Apr 15, 2024
@casperisfine
Copy link
Author

Thank you!

@casperisfine casperisfine deleted the fstr branch April 15, 2024 14:13
@kyrylo
Copy link
Collaborator

kyrylo commented Apr 15, 2024

I just released v1.1.0 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants