[#8815] Segfault in libc strlen, via rb_str_new2 — "Sean E. Russell" <ser@...>

Howdy,

12 messages 2006/09/09
[#8817] Re: Segfault in libc strlen, via rb_str_new2 — Eric Hodel <drbrain@...7.net> 2006/09/09

On Sep 8, 2006, at 10:10 PM, Sean E. Russell wrote:

Re: [PATCH] OptionParser < Hash

From: "greg weber" <eegreg@...>
Date: 2006-09-11 06:03:42 UTC
List: ruby-core #8834
> OptionParser's methods are partioned to 2 kinds.  Methods to register
> the options, and methods to parse the command line.  The former does
> modify the receiver, but the latter never.  I don't plan to change
> this concept.
>
This is my first patch submission, so I hope I am not being rude, and
I appreciate the your response and the work that everyone here does.
I think it is important to question anything that conflict with your
ideas about the architecture.  However, a change that conflicts with
an architectural idea does not in itself mean the change is bad.  It
could mean that the architectural idea is overly rigid.

My patch does seem kind of hackish.  Perhaps you would be more
comfortable with adding a state variable, @auto_options = {}, that
would implement this option hash instead of using self.  I don't see
any downside to this- users are free to ignore it.  Those who use it
will avoid creating a boilerplate outer class and boilerplate variable
settings, making them more productive and happier :)
>
>   @text = true
>   @eol = nil
>   OptionParser.new do |q|
>     ot = q.def_option("--text") {@text = true}
>     ob = q.def_option("--binary") {@text = false}
>     oe = q.def_option("--eol=EOL", %w[UNIX DOS OS9]) {|eol| @eol = eol}
>     q.exclusive(ob, oe)          # <=== eol and binary are exclusive
>     q.requires(oe, ot)           # <=== eol requires text
>   end
>
I do not see the exclusive and requires methods.  What version do I
need for these to work?

One more comment- I think the OptionParser library would do well to
make some of its public methods private or combine them.  The
multitude of public methods maked it harder to figure out which
methods should be used.  For example, it would perhaps be better to
eliminate on and just use define.  It would also be good to make order
and permute private, but callable from parse by setting keyword
arguments.

One more question- is there a way to collect the help output message
from OptionParser with RDoc?

Thank you
Greg Weber

In This Thread