From: "David A. Black" Date: 2008-08-14T06:43:47+09:00 Subject: [ruby-core:18278] Re: Am I right that this is wrong? Hi -- On Thu, 14 Aug 2008, Gregory Brown wrote: > On Wed, Aug 13, 2008 at 3:04 PM, David A. Black wrote: >> Hi -- >> >> On Thu, 14 Aug 2008, Yukihiro Matsumoto wrote: >> >>> Hi, >>> >>> In message "Re: [ruby-core:18263] Am I right that this is wrong?" >>> on Wed, 13 Aug 2008 22:33:18 +0900, "David A. Black" >>> writes: >>> >>> | * call-seq: >>> | * mod.instance_methods(include_super=true) => array >>> | * >>> | * Returns an array containing the names of public instance methods >>> | * in the receiver. For a module, these are the public methods; for a >>> | * class, they are the instance (not singleton) methods. With no >>> | * argument, or with an argument that is false, the >>> | * instance methods in mod are returned, otherwise the methods >>> | * in mod and mod's superclasses are returned. >>> | >>> |Since include_super defaults to true, I believe the "With no argument" >>> |statement is wrong. These arbitrary boolean arguments are definitely >>> |confusing, so I just wanted to make sure I'm right that it's wrong. >>> >>> The documentation is wrong, as you say. If many prefer the documented >>> behavior and want to change it, it is another story. >> >> There was a discussion about this at the Ruby Hoedown. As Jim Weirich >> pointed out, the nice thing about doing it the other way around is >> that you could do: >> >> MyClass.instance_methods(:ancestors => true) >> >> or >> >> MyClass.instance_methods(:with_ancestors) >> >> or whatever, whereas to make the argument false, you have to use false >> or nil which is very cryptic. > > Are you suggesting keeping a boolean signature and then passing things > like this in? > I think that's a little nasty. > > I've done stuff like: > > some_method_with_boolean_args(do_something=true) > > But I would feel uncomfortable with > > some_method_with_boolean_args(:do_something) > > I'm totally aware that in practice, there is little difference between the two. > However, I dislike the idea of a convention that creates a 'fake' > signature, especially in the first case. > > MyClass.instance_methods(:ancestors => true) > > makes me think that I can do: > > MyClass.instance_methods(:ancestors => false), and without a change to > the signature, that wouldn't be the case. I would actually prefer there to be separate methods for all these permutations (and I think Jim W. agrees). I just dislike the cryptic "false" so much that I'd rather do almost anything else. David -- Rails training from David A. Black and Ruby Power and Light: * Advancing With Rails August 18-21 Edison, NJ * Co-taught by D.A. Black and Erik Kastner See http://www.rubypal.com for details and updates!