[#10193] String.ord — David Flanagan <david@...>

Hi,

41 messages 2007/02/05
[#10197] Re: String.ord — Yukihiro Matsumoto <matz@...> 2007/02/06

Hi,

[#10198] Re: String.ord — David Flanagan <david@...> 2007/02/06

Yukihiro Matsumoto wrote:

[#10199] Re: String.ord — Daniel Berger <djberg96@...> 2007/02/06

David Flanagan wrote:

[#10200] Re: String.ord — David Flanagan <david@...> 2007/02/06

Daniel Berger wrote:

[#10208] Re: String.ord — "Nikolai Weibull" <now@...> 2007/02/06

On 2/6/07, David Flanagan <david@davidflanagan.com> wrote:

[#10213] Re: String.ord — David Flanagan <david@...> 2007/02/06

Nikolai Weibull wrote:

[#10215] Re: String.ord — "Nikolai Weibull" <now@...> 2007/02/06

On 2/6/07, David Flanagan <david@davidflanagan.com> wrote:

[#10216] Re: String.ord — David Flanagan <david@...> 2007/02/07

Nikolai Weibull wrote:

[#10288] Socket library should support abstract unix sockets — <noreply@...>

Bugs item #8597, was opened at 2007-02-13 16:10

12 messages 2007/02/13

[#10321] File.basename fails on Windows root paths — <noreply@...>

Bugs item #8676, was opened at 2007-02-15 10:09

11 messages 2007/02/15

[#10323] Trouble with xmlrpc — James Edward Gray II <james@...>

Some of the Ruby code used by TextMate makes use of xmlrpc/

31 messages 2007/02/15
[#10324] Re: Trouble with xmlrpc — "Berger, Daniel" <Daniel.Berger@...> 2007/02/15

> -----Original Message-----

[#10326] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/15

On Feb 15, 2007, at 1:29 PM, Berger, Daniel wrote:

[#10342] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/16

While I am complaining about xmlrpc, we have another issue. It's

[#10343] Re: Trouble with xmlrpc — Alex Young <alex@...> 2007/02/16

James Edward Gray II wrote:

[#10344] Re: Trouble with xmlrpc — James Edward Gray II <james@...> 2007/02/16

On Feb 16, 2007, at 12:08 PM, Alex Young wrote:

[ ruby-Bugs-8384 ] Discrepancy between GetoptLong.new and documentation

From: <noreply@...>
Date: 2007-02-02 09:06:33 UTC
List: ruby-core #10172
Bugs item #8384, was opened at 2007-02-02 10:06
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1698&aid=8384&group_id=426

Category: Standard Library
Group: 1.8.5
Status: Open
Resolution: None
Priority: 3
Submitted By: Roel Harbers (rharbers)
Assigned to: Nobody (None)
Summary: Discrepancy between GetoptLong.new and documentation

Initial Comment:
According to the documentation for getoptlong.rb, the GetoptLong.new method requires an array of arrays to be passed:

  # The options to support are passed to new() as an array of arrays.
  # Each sub-array contains any number of String option names which carry 
  # the same meaning, and one of the following flags:

However, this code fails:
  require 'getoptlong'
  options = GetoptLong.new(
    [
      ['-a', GetoptLong::NO_ARGUMENT],
      ['-b', GetoptLong::NO_ARGUMENT],
    ]
  )

This works:
  require 'getoptlong'
  options = GetoptLong.new(
    ['-a', GetoptLong::NO_ARGUMENT],
    ['-b', GetoptLong::NO_ARGUMENT]
  )

Either the documentation could be fixed, or the call could accept an array of arrays. Personally, I prefer the latter, since it allows something like this:

  options = GetoptLong.new(
    [
      ['-a', GetoptLong::NO_ARGUMENT],
      ['-b', GetoptLong::NO_ARGUMENT],
#     ['--debug', GetoptLong::NO_ARGUMENT],
    ]
  )

which the other form does not allow without removing the comma from the -b line too.

I made a patch againt 1.8.5 that lets set_options (and by extension initialize) accept both forms.

What do you people think?

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=1698&aid=8384&group_id=426

In This Thread

Prev Next