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

Issue #11491 has been updated by Benoit Daloze.


#receiver is not ideal since it has a different meaning for Method ("receiver type" is more what we want).
In JRuby it is called "origin" ("orig" in MRI) and the documentation of UnboundMethod says:

    Unbound methods can only be called after they are bound to an
    object. That object must be a kind_of? the method's original class.

So I propose #origin, which goes well along #owner.

As for the instance/singleton method, maybe it would make sense to expose Class#singleton?.
But I am unsure of what would be a valid use case for such a predicate. Why do you want to know if it is a "class method" or not?

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

* Author: Justin Searls
* Status: Open
* 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/