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