From: Tanaka Akira <akr@...17n.org>
Date: 2003-11-19T00:11:34+09:00
Subject: Re: open-uri patch, added progress_proc hook

In article <20031117210516.GA25730@student.ei.uni-stuttgart.de>,
  Mauricio Fern�ndez <batsman.geo@yahoo.com> writes:

> IMHO
> the validity of the arguments _as a whole_ can easily be factored into
> a method of OpenURI::Options.

Unfortunately, options may vary depends on a kind of target:
URI::HTTP, URI::FTP and others.

Since open-uri is a delegator to open any kind of URIs and other
resources which have public `open' method, fixed set of options is not
suitable.  So, validity checking cannot be factored into single class.

> Also, the foo= instance methods of OpenURI can perform the checks you'd
> have to do in open otherwise.
> If the options become more "intelligent" at some point in the future,
> it would be nice to have them in a full-blown object.
> This seems to advocate for something like
>
> options = Options.new
> options.progress_proc = proc { }
> ...
> open("http://...", ..., options)
>
> but I believe the "impedance mismatch" is too high in that case; I
> find... feel the proc{|e| e.xxx=...} idiom is "lighter".

I feel OpenURI::OptXXX => ... is more lighter than proc {|e| ... }.
I feel :xxx => ... is more lighter than OpenURI::OptXXX.

I feel :xxx => ... style matches with Kernel#open.  However it tends
to have no error checking.

Maybe, implementing error checking with :xxx => ... style is a
solution.  But I'm not sure that unknown option should be cause
exception.

> More importantly :-) I find one argument (even though it's a proc)
> more pleasant to the eye than several key => val pairs.

I don't feel so.

> And you can save
> some typing if you want (proc {|e| e.progress_proc = ...}) without having
> to include OpenURI.

In this point of view, :xxx => ... is best (shortest).

Further, it will be more shorter with keyword argument on Ruby2, maybe.

> class OpenURI
> 	class Options
> 		def method_missing(meth, *args)
> 			# any behavior you like here, including raise NameError
> 		end
> 	end
> end
>
> it won't catch all typos unless you use undef_method (but that's not
> a problem), but OpenURI::id wouldn't be caught either (this is more than
> a mere typo, though).

I meant that both are no problem.  So don't advocate such trick.
Such trick tends to cause trouble.

> Summarizing: putting the options in an object gives you more power
> you might someday find useful. The proc idiom provides not too heavy a
> way to do so.

Someday?  It's violates YAGNI.
-- 
Tanaka Akira