[#18121] [Ruby 1.8.7 - Bug #405] (Open) ssl.rb:31: [BUG] Bus Error — Anonymous <redmine@...>

Issue #405 has been reported by Anonymous.

14 messages 2008/08/04

[#18130] Re: New array methods cycle, choice, shuffle (plus bug in cycle) — Brian Candler <B.Candler@...>

> Seriously though... Array.first is a noun.

10 messages 2008/08/05

[#18319] NEW Command: absolute_path() -- — "C.E. Thornton" <admin@...>

Core,

14 messages 2008/08/16
[#18321] Re: NEW Command: absolute_path() -- — Yukihiro Matsumoto <matz@...> 2008/08/18

Hi,

[#18381] [Bug #496] DRb.start_service(nil) is very slow — Hongli Lai <redmine@...>

Bug #496: DRb.start_service(nil) is very slow

11 messages 2008/08/25

[ruby-core:18276] Re: Am I right that this is wrong?

From: "Gregory Brown" <gregory.t.brown@...>
Date: 2008-08-13 19:09:22 UTC
List: ruby-core #18276
On Wed, Aug 13, 2008 at 3:04 PM, David A. Black <dblack@rubypal.com> 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"
>> <dblack@rubypal.com> 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 <code>false</code>, the
>> |  *  instance methods in <i>mod</i> are returned, otherwise the methods
>> |  *  in <i>mod</i> and <i>mod</i>'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.

-greg



-- 
Technical Blaag at: http://blog.majesticseacreature.com | Non-tech
stuff at: http://metametta.blogspot.com

In This Thread