In article <20031116142119.GA18339 / student.ei.uni-stuttgart.de>,
  Mauricio Fern?ndez <batsman.geo / yahoo.com> writes:

> What about
>
> open("http://...", ... current options ..., 
>      proc { |extconf|
> 		extconf.progress_proc = proc {  }
> 		extconf.foo = ...
> 	 }
> )
>
> ?
>
> extconf would be an object of type OpenURI::Options or so.
>
> This scheme is AFAIK backwards compatible, extensible (just add accessors
> to OpenURI::Options), can detect wrong parameters and ensures open won't
> be given non-existent arguments. You don't have to remember the order of
> arguments nor to put nil for those not needed.  Moreover, the validity
> of the arguments _as a whole_ can easily be factored into a method of
> OpenURI::Options.

What's an advantage over mine?

Both detects typos on option names.  However exception class is different:
extconf.typo raises NoMethodError and OpenURI::OptTypo raises NameError.
-- 
Tanaka Akira