# \#method(false) returns singleton methods? **URL:** \ **Category:** Ruby\ **Created:** [November 29, 2006, 11:41pm UTC](https://www.ruby-forum.com/t/method-false-returns-singleton-methods/77720 "2006-11-29T23:41:35Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [November 29, 2006, 11:41pm UTC](https://www.ruby-forum.com/t/method-false-returns-singleton-methods/77720/1 "2006-11-29T23:41:35Z")
I had a hard enough time recalling that #instance\_methods only returns public methods rather then all methods, and after all this time I’m only now discovering that #methods(false) only returns singleton methods? Why? Has it changed? Am I loosing my mind? The ri doumentation fails even to metion the parameter. The asymmetry of these method-methods continually wastes effort. irb(main):001:0\> class A irb(main):002:1\> def a; end irb(main):003:1\> private irb(main):004:1\> def b; end irb(main):005:1\> protected irb(main):006:1\> def c; end irb(main):007:1\> end =\> nil irb(main):008:0\> a = A.new =\> #\ irb(main):009:0\> def a.d; end =\> nil irb(main):010:0\> a.methods =\> [“to\_a”, “respond\_to?”, “type”, “protected\_methods”, “eql?”, “instance\_variable\_set”, “is\_a?”, “hash”, “to\_s”, “send”, “class”, “tainted?”, “private\_methods”, “ **send** ”, “untaint”, “a”, “id”, “inspect”, “instance\_eval”, “clone”, “public\_methods”, “extend”, “freeze”, “display”, “ **id** ”, “d”, “==”, “methods”, “method”, “===”, “nil?”, “dup”, “instance\_variables”, “instance\_of?”, “object\_id”, “=~”, “c”, “singleton\_methods”, “equal?”, “taint”, “frozen?”, “instance\_variable\_get”, “kind\_of?”] irb(main):011:0\> a.methods(false) =\> [“d”] ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [November 30, 2006, 5:42am UTC](https://www.ruby-forum.com/t/method-false-returns-singleton-methods/77720/2 "2006-11-30T05:42:39Z")
On 11/30/06, Trans [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > I had a hard enough time recalling that #instance\_methods only returns > public methods rather then all methods, and after all this time I’m > only now discovering that #methods(false) only returns singleton > methods? Why? Has it changed? Am I loosing my mind? It hasn’t changed recently: Tue May 6 14:39:36 2003 Yukihiro M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ``` * object.c (rb_obj_methods): list singleton methods if recur argument is false; list all methods otherwise. ``` > The ri doumentation fails even to metion the parameter. You’re right. I reckon a documentation patch would be well-appreciated… 😉 ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [November 30, 2006, 7:20pm UTC](https://www.ruby-forum.com/t/method-false-returns-singleton-methods/77720/3 "2006-11-30T19:20:47Z")
George O. wrote: > ``` > * object.c (rb_obj_methods): list singleton methods if recur > argument is false; list all methods otherwise. > > ``` Thanks. I suppose matz has his reasons. Though I can’t say I quite phatom them. Even his changelog entry isn;t exactly corrent since only _public_ singleton methods show up if argument is false; and list all _public_ methods otherwise. I have to agree with David Black that this true false parameter has no sematic quality. That is differs in result from obj.methods to class.methods is further confusing on top of the distinctions between methods, public\_methods, etc. This was brought up a long time ago, but I still agress with the idea of a sinlge interface that takes symbolic “filters”. obj.methods(:singleton) obj.methods(:public) obj.methods(:all) obj.methods(:private, :public) # combination etc. > > The ri doumentation fails even to metion the parameter. > You’re right. I reckon a documentation patch would be well-appreciated… 😉 Hehe. Well, that’s going to have be left up to one of our doc specialists. I already have enough cod eof my own that need documenting. 🙂 T. ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [December 8, 2006, 3:42pm UTC](https://www.ruby-forum.com/t/method-false-returns-singleton-methods/77720/4 "2006-12-08T15:42:46Z")
Peña wrote: > # obj.methods(:singleton) > > # obj.methods(:public) > > # obj.methods(:all) > > # obj.methods(:private, :public) # combination > > +10 big up 🙂 just to relate this to #each in the method mode var conversation. I can understand matz steering clear of symbolic parameters on the whole, but in this case I agree with your +10 assessment. It’s just too fitting a use case. the biggest case in point, how to gather all methods. this blows: mod.public\_instance\_methods+mod.private\_instance\_methods+mod.protected\_instance\_methods t. ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [December 4, 2006, 5:02am UTC](https://www.ruby-forum.com/t/method-false-returns-singleton-methods/77720/5 "2006-12-04T05:02:21Z")
:From =\> “Trans [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)]” # I have to agree with David Black that this true false parameter has no # sematic quality. That is differs in result from obj.methods to # class.methods is further confusing on top of the distinctions between # methods, public\_methods, etc. This was brought up a long # time ago, but # I still agress with the idea of a sinlge interface that takes symbolic # “filters”. # # obj.methods(:singleton) # obj.methods(:public) # obj.methods(:all) # obj.methods(:private, :public) # combination +10 -botp ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [December 9, 2006, 8:23am UTC](https://www.ruby-forum.com/t/method-false-returns-singleton-methods/77720/6 "2006-12-09T08:23:00Z")
On 12/1/06, Trans [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > On 11/30/06, Trans [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > Thanks. I suppose matz has his reasons. Though I can’t say I quite > > phatom them. Even his changelog entry isn;t exactly corrent since only > > _public_ singleton methods show up if argument is false; and list all > > _public_ methods otherwise. Almost right; it’s actually _nonprivate_ methods. 😉 And yeah, there’s a peculiar asymmetry, between #methods and #(public|protected|private)\_methods in exactly what gets included, even with the same argument. For example, #methods(false) only hits the singleton class, but #public\_methods(false) goes up the ancestor chain to and including #class . In fact, #methods(false) is actually equivalent to #singleton\_methods(false), yet another #\*\_method method with different boolean-parameter semantics. :-/ class B def boo end end class D \< B def doo end end d = D.new module M def moo end end class \<\< d include M def scoo end end # so ancestor chain is: #Class:d \< M \< D \< B d.methods.grep(/oo/) #=\> [“boo”, “scoo”, “doo”, “moo”] d.methods(false).grep(/oo/) #=\> [“scoo”] d.public\_methods.grep(/oo/) #=\> [“boo”, “scoo”, “doo”, “moo”] d.public\_methods(false).grep(/oo/) #=\> [“doo”, “scoo”, “moo”] d.singleton\_methods.grep(/oo/) #=\> [“scoo”, “moo”] d.singleton\_methods(false).grep(/oo/) #=\> [“scoo”] > obj.methods(:private, :public) # combination > > etc. I agree that the boolean parameter is not ideal. I’m not entirely sold on your suggestion yet either, though. Firstly, I’m not so sure :singleton belongs in there. I’d expect (:singleton, :public) to mean “singleton AND public”, whereas (:public, :private) looks more like “public OR private”, and mushing 'em all up feels a bit icky. This still doesn’t cover the current semantics of #singleton\_methods(true), either. Would we need another filter to mean “singleton with included modules”? The other bit of irkage I forsee with this is that presumably no args would mean return [], which means you’d lose the convenience of querying things usefully with plain old “thing.methods”. > Hehe. Well, that’s going to have be left up to one of our doc > specialists. I already have enough cod eof my own that need > documenting. 🙂 Well, I’d hardly label myself a “doc specialist”, but if you won’t, I will. After all, what code could be more worth documenting than the ruby core? 😉 ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [December 14, 2006, 2:48am UTC](https://www.ruby-forum.com/t/method-false-returns-singleton-methods/77720/7 "2006-12-14T02:48:29Z")
On 12/10/06, Trans [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > > The other bit of irkage I forsee with this is that presumably no args > > would mean return [], which means you’d lose the convenience of > > querying things usefully with plain old “thing.methods”. > > Good point about singleton, I suppose the easiest adjustment would be > :singleton\_public, :singleton\_private, :singleton\_protected and > :singleton\_all. Hmm, looks like a small combinatorial explosion. ☹ > Where :singleton itself could just be a synonym for > :singleton\_public. Given how things currently work if no symbol is > given at all it would be the same as if just :public were given. That > would help a little with backwords compatability. Howerver there’s > still the question of ancestor inclusion --and I suppose just adding > :ancestors would be enough for that. That’s what I was kinda hoping to avoid–special cases. Some crazy hacker’s gonna be building the arg list programmatically one day, and find they have to treat the empty list specially. I suppose you could do something like: def methods(visibilities=[:public, :protected], restriction=nil) … end Or maaaybe: def methods(\*args) if !args.empty? && args.all?{|a| a.respond\_to?(:to\_sym)} visibilities = args.map{|a| a.to\_sym} restriction = nil else visibilities, restriction = \*args visibilities ||= [:public, :protected] end … end …where restriction would be things like :singleton and :singleton\_with\_modules (or something–“ancestors” is too generic IMHO; it strictly means just the modules included in the singleton class, and nothing more), or nil for the whole ancestor chain. But OTOH, it’s starting to look a little scary now. Maybe I just need time to let it sink in. > Aside, it would be rather interesting if methods could be handled 1st > class. Then: > > obj.methods.select{ |m| m.singleton? } > obj.methods.select{ |m| m.public? or m.private? } > obj.methods.select{ |m| m.inherited? } Conceptually pleasing maybe, though quite verbose if all you want are names. :-/ ---
**Author:** ![Trans](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/dfb087/32.png) [@Trans](https://www.ruby-forum.com/u/Trans)\ **Post date:** [December 9, 2006, 11:44pm UTC](https://www.ruby-forum.com/t/method-false-returns-singleton-methods/77720/8 "2006-12-09T23:44:17Z")
George O. wrote: > #(public|protected|private)\_methods in exactly what gets included, > > end > d.methods(false).grep(/oo/) #=\> [“scoo”] > > > “filters”. > > :singleton belongs in there. I’d expect (:singleton, :public) to mean > > “singleton AND public”, whereas (:public, :private) looks more like > > “public OR private”, and mushing 'em all up feels a bit icky. This > > still doesn’t cover the current semantics of #singleton\_methods(true), > > either. Would we need another filter to mean “singleton with included > > modules”? > > The other bit of irkage I forsee with this is that presumably no args > would mean return [], which means you’d lose the convenience of > querying things usefully with plain old “thing.methods”. Good point about singleton, I suppose the easiest adjustment would be :singleton\_public, :singleton\_private, :singleton\_protected and :singleton\_all. Where :singleton itself could just be a synonym for :singleton\_public. Given how things currently work if no symbol is given at all it would be the same as if just :public were given. That would help a little with backwords compatability. Howerver there’s still the question of ancestor inclusion --and I suppose just adding :ancestors would be enough for that. Aside, it would be rather interesting if methods could be handled 1st class. Then: obj.methods.select{ |m| m.singleton? } obj.methods.select{ |m| m.public? or m.private? } obj.methods.select{ |m| m.inherited? } > Well, I’d hardly label myself a “doc specialist”, but if you won’t, I > will. After all, what code could be more worth documenting than the > ruby core? 😉 Do that and you will be! 😉 As for me, I just mean I don’t have the time. t.