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

Jump to bottom

Tiny improvements of Range for X19 #2272

Closed
wants to merge 2 commits into from
Closed

Tiny improvements of Range for X19 #2272

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e0e0e6f
Fix an protected method in Range for X19
kachick Apr 12, 2013
c7943b0
Clarify a implementing Range#=== for X19
kachick Apr 12, 2013
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
3 changes: 2 additions & 1 deletion kernel/common/range19.rb
View file
Open in desktop
@@ -1,6 +1,7 @@
# -*- encoding: us-ascii -*-

class Range
# Don't use `alias_method` for #===. `Delegate to #include?` is a spec.
Copy link
Contributor

Choose a reason for hiding this comment

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

If this is defined as the spec, we should also add a RubySpec for this behavior

Copy link
Member Author

Choose a reason for hiding this comment

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

Sorry spec is range/case_compare_spec.
But I want to this comment to here for readability.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, sorry from my side, I didn't realize it was just adding this as a comment and not changing the actual code. Were you surprised by this behavior? Behavior like this exists is various other places in Ruby and we don't have comments in all the other places. The upside of actually having a spec for this, is that even if people would think about changing it, the spec would fail and would tell people exactly what is wrong. So I don't really see a big advantage of adding this comment here.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, I was very surprised this behavior :)
And i was helped by a coment from non updated version guard in spec

But this is my problem, you are right !

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, adding comments like this is often a balancing act. Since the case of a certain being implement with another and not an alias happens in a few more places, it's not that much an edge case as probably the case you mentioned. I remember fixing 17e1e62, but didn't add a comment for that case either.

Copy link
Member Author

Choose a reason for hiding this comment

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

Great reference! Thanks!

def ===(value)
include?(value)
end
Expand Down Expand Up @@ -83,6 +84,6 @@ def min(&block)
protected

def can_iterate_from?(object)
first.respond_to?(:succ) && !object.kind_of?(Time)
object.respond_to?(:succ) && !object.kind_of?(Time)
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here, if this fixes a bug, we should also add a spec for it

Copy link
Member Author

Choose a reason for hiding this comment

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

OK.
But that is difficult for me.
I remove this commit.

Copy link
Contributor

Choose a reason for hiding this comment

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

Well, if this is a bug, it would be good to fix it. Do you have a script perhaps that shows the problem? We can work on making a proper spec out of that then.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks!

But i have no example for this commit.
This commit from Range#each already gotten the first element.
And this method is not used by other objects.
Prefer private to protected for me.

Copy link
Contributor

Choose a reason for hiding this comment

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

We can make it private yeah, seems better to me then. Also inside the kernel/ code we prefer to use explicitly making things private, so basically doing private :method_name after the definition, instead of changing the default visibility by just a plain 'private'. We should probably apply this change for visibility to both 1.8 and 1.9 mode.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll commit it via other pull-request without "first -> object" modifying.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm fine with the first -> object change, seems to make sense to me, even though it will hardly ever be a problem in practice.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've got it. :)

end
end