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

Issue #11491 has been updated by Benoit Daloze.


Nobuyoshi Nakada wrote:
> Benoit Daloze wrote:
> > So I propose #origin, which goes well along #owner.
> 
> How does it differ than `#owner`?

It would return String in the example above.

> A `Method` is a method, the difference from `UnboundMethod` is just if it has a receiver.
> If `respond_to?(:receiver)` returns `true`, it's a callable (and bound) Method.
> 
> If a new method is *really* needed, `callable?` or `bound?` probably.

I was just commenting on the naming.
Having the ability to check if a UnboundMethod can be bound to a given receiver seems useful though and #owner does not allow this.

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

* Author: Justin Searls
* Status: Feedback
* Priority: Normal
* Assignee: 
----------------------------------------
(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/