Tanaka Akira wrote:
> I may also want to use proc for:
> * process content fragments instead of byte count.
> * handle request/response header for *each* request by redirection.
>   (for authentication, cookie, etc.)
> * etc.
>
> In future, open may have many proc arguments as:
> 
> open(name, progress_proc, content_progress_proc,
>   extra_request_header_proc, handle_response_header_proc, ...)
>
> I don't like that.
> I don't want to remember the order.
> I don't want to specify number of nil for arguments I don't care.
> 
> So, although it has no backward compatibility, it has extensibility
> problem.

[the trouble with YAGNI is that -- if you're writing a library -- YAreGNI,
at least where 'it' is room to maneuver ;-)]

the extensibility problem is part of the reason i suggested a new class. i
imagined something along these lines:

 class UriOpener
  def monitorProgress(&block)
   @progress_monitor = block
  end

  def handleResponseHeader(&block)
   @response_header_handler = block
  end

  ...

  def open_uri(name)
   ...
  end
 end

that would let you use the 'natural' Ruby block syntax, but also let you
have an arbitrary number of blocks. i think Matz made a good decision in
'limiting' us to one block parameter per method, because anything more would
be terribly confusing (and suggest that the method in question doesn't Do
One Thing).

the major change would be that OpenURI's work would move into UriOpener, and
OpenURI.open_uri would now create a UriOpener instance, and invoke the
open_uri on that instance.

unless, of course, i'm missing something. i don't really understand why
conversation switched to Procs.

> If the benefit of that is parameter checking, how about this style:
> 
> open("http://...", OpenURI::OptProgressProc => lambda {|s| ... })
> 
> OpenURI::OptProgressProc is a some constant of a symbol.

that would be better than the kind of hash used in Ruby's telnet, for
example. if there's one thing worse than an error that isn't detected until
run-time, it's an error that isn't even detected at run-time!

i still prefer factoring the behavior out into a new class that gives access
to all the fancier functionality, though.

 --elliott


*********************************************************************
This e-mail and any attachment is confidential. It may only be read, copied and used by the intended recipient(s). If you are not the intended recipient(s), you may not copy, use, distribute, forward, store or disclose this e-mail or any attachment. If you are not the intended recipient(s) or have otherwise received this e-mail in error, you should destroy it and any attachment and notify the sender by reply e-mail or send a message to sysadmin / bluearc.com
*********************************************************************