[ruby-core:70610] [Ruby trunk - Feature #11491] Add descriptive methods to Method & UnboundMethod

Issue #11491 has been updated by Myron Marston.


I think that `Method#instance_method?` and `UnboundMethod#instance_method?` would be very confusing, because my mental model is that _every_ method is an instance method of some class -- it's just that the class might be a singleton class.  After all, if you do `ENV.singleton_class.instance_method(:fetch)` it returns an `UnboundMethod` object for the `fetch` method that's defined as a singleton method on `ENV`.

I think it would make more sense to add a `#singleton_method?` predicate.  While every method is an instance method of some class, only some methods are singleton methods.

----------------------------------------
Feature #11491: Add descriptive methods to Method & UnboundMethod
https://bugs.ruby-lang.org/issues/11491#change-54016

* Author: Justin Searls
* Status: Open
* Priority: Normal
* Assignee: Aaron Patterson
----------------------------------------
(Using Ruby Version 2.2.2)

I would like Method and Unbound Method to provide methods to provide the following additional information:

* `Method#instance_method?` and `UnboundMethod#instance_method?` to indicate whether the method is an instance or a class method
* `UnboundMethod#receiver` to provide the type required to be passed to `UnboundMethod#bind`

I believe this information is already probably readily available, because it can be gleaned from `Method#to_s` and `UnboundMethod#to_s`. For example:

```
> String.instance_method(:taint)
=> #<UnboundMethod: String(Kernel)#taint>
```

The above output tells us the eligible receiver type is String, the owner is Kernel, the "#" indicates an instance_method, and the name is taint. However, with the current UnboundMethod API, we can only tell the owner and the name. 

It would be very useful to also see the receiver type and whether the method is an instance_method without performing Regex on the output of `to_s`.

In particular, `UnboundMethod#receiver` would be useful, even though UnboundMethod does not logically have a receiver, because it would make it easier to tell what type of objects can be passed to `UnboundMethod#bind` without raising a TypeError.




-- 
https://bugs.ruby-lang.org/