Feature #11689: Add methods allow us to get visibility from Method and UnboundMethod object.

• Status: Open
• Assignee: -
• Target version: -

[yui-knk (Kaneko Yuichiro)]

Add Method#visibility and UnboundMethod#visibility for getting visibility from Method and UnboundMethod object.
In GitHub https://github.com/ruby/ruby/pull/1098.

[hsbt (Hiroshi SHIBATA)]

What's use-case for these methods?

At least, You should describe use-case with feature request.

[yui-knk (Kaneko Yuichiro)]

Sorry.

These methods are useful for inspecting Method object (e.g. debugging or documenting).
Currently if we need information about visibility, we should check owner.public_instance_methods, owner.protected_instance_methods, and owner.private_instance_methods:
see also pry: https://github.com/pry/pry/blob/1f3f7e7ceff27ef516536849fc44fdf010f91c93/lib/pry/method.rb#L343

[MikeVastola (Mike Vastola)]

Just wanted to second this FR as something I'd find useful.

Also, it would be nice to have associated predicate methods (i.e. Method#public?, Method#protected? and Method#private?)

[yui-knk (Kaneko Yuichiro)]

Thanks for your comment.
Can you show me the use cases where predicate methods are useful?
I think these predicate methods can be implemented by using #visibility method, so these predicate methods should not be needed as core features.

[MikeVastola (Mike Vastola)]

Oh, sorry. I missed where you were looking for an example before. Here's a good one from the popular activesupport gem: here.

As for the predicate methods, yes, they can be derrived from core methods and they -- like most core predicate methods, -- would be for convenience, but I disagree that that should be the determining factor. The same could be said for #nil?, #is_a?, #respond_to? and #*_defined? -- the functionality of which could be accomplished by checking the results of other core methods.

[shevegen (Robert A. Heiler)]

(I think it may be easier to file a separate issue for the predicate methods,
such as Method#public?, Method#protected? or Method#private?).

Kaneko Yuichiro added the issue to the next upcoming developer meeting. Let's
see to the upcoming discussion of matz and the core developers and matz.

[matz (Yukihiro Matsumoto)]

The proposal sounds nice, but I am not fully satisfied with the term visibility. So how about adding public?, private? and protected? methods instead?

Matz.

[MikeVastola (Mike Vastola)]

I mean, as seen in yui-knk's example with pry, I think it's helpful to be able to essentially do send("#{method.visibility}_instance_methods"). I'm not picky on the name though if there is something better than visibility.

But I think it makes sense to address any/all methods that are introduced in this issue.

[mame (Yusuke Endoh)]

I don't think that send("#{method.visibility}_instance_methods") would be a frequent, strongly-recommended idiom. You can do it more explicitly as follows.

def visibility(method)
  case
  when method.public?    then "public_instance_methods"
  when method.protected? then "protected_instance_methods"
  when method.private?   then "private_instance_methods"
  else raise "unknown method type"
  end
end

This code would require work if a new visibility is introduced. But, there is no plan to add a new visibility in foreseeable future. Also, if something is actually introduced, there is no guarantee that the idiom would work as is.

[Eregon (Benoit Daloze)]

I think visibility is the perfect, accurate and unambiguous term for this (e.g., it's even used in the documentation of #private).
Returning the corresponding Symbol also seems very intuitive.

So take my vote as +1 for Method#visibility and -1 for 3 methods which seem very inconvenient to use.
Basically, it's 1 method versus 3 and it's strictly more expressive/powerful (the result can be displayed easily for introspection, and also compared to a known visibility).

[mame (Yusuke Endoh)]

FYI: The reason why matz does not like the term "visibility", is because the method attribute is not a visibility. In fact, all methods are visible in Ruby. Instead, the method attribute restricts how and where it can be called. We briefly discussed another name candidate at the meeting, but we couldn't find a good name of the concept. Then matz chose the three methods (public?, etc.) because we can avoid deciding the name.

[Eregon (Benoit Daloze)]

mame (Yusuke Endoh) wrote:

FYI: The reason why matz does not like the term "visibility", is because the method attribute is not a visibility. In fact, all methods are visible in Ruby. Instead, the method attribute restricts how and where it can be called. We briefly discussed another name candidate at the meeting, but we couldn't find a good name of the concept. Then matz chose the three methods (public?, etc.) because we can avoid deciding the name.

Thanks for the information :)

Right, the visibility does not affect how to call the method reflectively (which is done with Method#call), but reflects the visibility in the context of normal calls.
To be honest, I expect very few people to be confused by this.
I think it's clear it means the definition time visibility.
Metaprogramming methods in general ignore visibility (or enforce public with #public_send), so a visibility for how to call the Method object wouldn't make sense anyway.

Instead, the method attribute restricts how and where it can be called.
We briefly discussed another name candidate at the meeting, but we couldn't find a good name of the concept.

Visibility is the standard term to talk about public/protected/private and restrictions of how and where a method can be called, in all languages I know.
I think no other term makes more sense than visibility, and it is a well-known concept in programming languages.
Maybe in other natural languages this is confusing? I think in English it's as clear as it can be for an established concept.

In fact, all methods are visible in Ruby.

I'm not sure what you mean here. But one could say "method m in class A is not visible to instances of class B" and that would apply to Ruby if m is private.

[duerst (Martin Dürst)]

I agree that #visibility is the best solution. When somebody mentioned this at the recent Ruby committers' meeting, I immediately thought "that's it". Benoit provides some more background.

There are arguments that this may be misunderstood, but so might the original keywords public, protected, and private, and many other Ruby keywords and names. Ruby users already have to learn that private doesn't really mean private, that in Ruby, there's always some metaprogamming workaround. Once they now it, they will apply this to #visibility without much problems.

[jacobevelyn (Jacob Evelyn)]

I'd also like to advocate for this. We're working on a gem that allows you to easily memoize a method while still preserving that method's visibility, and without Method#visibility we have to awkwardly hack around it:

method_visibility = if private_method_defined?(method_name)
                      :private
                    elsif protected_method_defined?(method_name)
                      :protected
                    else
                      :public
                    end

[jeremyevans0 (Jeremy Evans)]

I've submitted a pull request that implements @matz's idea of public?, private?, and protected?: https://github.com/ruby/ruby/pull/5040

[sawa (Tsuyoshi Sawada)]

jeremyevans0 (Jeremy Evans) wrote in #note-15:

I've submitted a pull request that implements @matz's idea of public?, private?, and protected?: https://github.com/ruby/ruby/pull/5040

I see that there is still a comment in the pull request requesting for a single method that covers them.

mame (Yusuke Endoh) wrote in #note-11:

FYI: The reason why matz does not like the term "visibility", is because the method attribute is not a visibility. In fact, all methods are visible in Ruby. Instead, the method attribute restricts how and where it can be called. We briefly discussed another name candidate at the meeting, but we couldn't find a good name of the concept. Then matz chose the three methods (public?, etc.) because we can avoid deciding the name.

What about Method#privacy # => :private / :protected / :public and UnboundMethod#privacy # => :private / :protected / :public, then?

[Eregon (Benoit Daloze)]

IMHO it'd be good to rediscuss this at a dev meeting.
It seems most people agree that Method#visibility would be better and more convenient (also @samuel on the PR).
Potential for confusion seems extremely low (to me).

[matz (Yukihiro Matsumoto)]

I still don't accept the term visibility. If everyone can accept public?, private? and protected?, I am OK with them.
If not, we need a new term to replace visibility.

Matz.

[Eregon (Benoit Daloze)]

I think #visibility is better, but to make progress on this I'm not against adding public?/private?/protected? instead.
It seems hard to find a new term that would fit here.

[austin (Austin Ziegler)]

Eregon (Benoit Daloze) wrote in #note-19:

I think #visibility is better, but to make progress on this I'm not against adding public?/private?/protected? instead.
It seems hard to find a new term that would fit here.

C++ and Java call these access specifiers, so maybe #access instead of #visibility? Alternatively, a bit longer maybe #access_level?

[Dan0042 (Daniel DeLorme)]

Suggestions: #protection / #protection_level / #isolation / #isolation_level

[jeremyevans0 (Jeremy Evans)]

I agree with @Eregon (Benoit Daloze), to make progress, it's best to merge support for public?, private? and protected?. Anyone who wants to have a visibility method can then implement it easily:

class Method
  def visibility
    return :public if public?
    return :private if private?
    :protected
  end
end

Is there anyone who objects to adding public?, private? and protected?? Unless there are objections, or someone comes up with a new term to replace visibility that @matz (Yukihiro Matsumoto) accepts, I plan to merge the pull request after the next developer meeting.

• Status changed from Open to Closed

Applied in changeset git|27278150685e738f84105d09843d3ba371146c7a.

---

Add {Method,UnboundMethod}#{public?,private?,protected?}

These methods allow for checking whether the method has that
visibility.

Implements [Feature #11689]

[matz (Yukihiro Matsumoto)]

When investigating #18435, I realized the visibility of a method is not an attribute of the method. Instead, each class should have lists of methods for each visibility. Otherwise, we would face issues like #18729 and #18751. With this understanding, Method and UnboundMethod classes should not have proposed methods. Although those methods have already been shipped with 3.1, I propose to remove the methods. I estimate the impact of removing those methods is minimal.

Matz.

[jeremyevans0 (Jeremy Evans)]

matz (Yukihiro Matsumoto) wrote in #note-24:

When investigating #18435, I realized the visibility of a method is not an attribute of the method. Instead, each class should have lists of methods for each visibility. Otherwise, we would face issues like #18729 and #18751. With this understanding, Method and UnboundMethod classes should not have proposed methods. Although those methods have already been shipped with 3.1, I propose to remove the methods. I estimate the impact of removing those methods is minimal.

I've submitted a pull request to revert this feature: https://github.com/ruby/ruby/pull/5974

[Eregon (Benoit Daloze)]

• Related to Bug #18435: Calling `protected` on ancestor method changes result of `instance_methods(false)` added
• Related to Bug #18729: Method#owner and UnboundMethod#owner are incorrect after using Module#public/protected/private added
• Related to Bug #18751: Regression on master for Method#== when comparing public with private method added

[Eregon (Benoit Daloze)]

• Status changed from Closed to Open

(I reopen because the new methods or equivalent functionality is not present on current master.)

Since https://github.com/ruby/ruby/pull/6242, both #18729 and #18751 are fixed.
Also "Visibility is an attribute of the method entry in a class, not an attribute of the Method object." is not a problem because now Method == method entry :)

Therefore I think we can now add {Method,UnboundMethod}#{public?,private?,protected?} again without any issue, and they will work intuitively/correctly.
@matz (Yukihiro Matsumoto) Is it OK?

[Eregon (Benoit Daloze)]

matz (Yukihiro Matsumoto) wrote in #note-24:

Instead, each class should have lists of methods for each visibility.

I realize now you mean the existing Module#{public_instance_methods,protected_instance_methods,private_instance_methods}.
Then the functionality is technically already there but it's less convenient than what this ticket asks for and a lot less efficient.
I think we should add {Method,UnboundMethod}#{public?,private?,protected?} again.