In article <200312021120.27331.ser / germane-software.com>,
  Sean E Russell <ser / germane-software.com> writes:

> What were your search terms?

I searched "=>".

> Try searching for "whitespace" or "raw".  Those 
> are two common attributes controlled by the hash arguments.

I see.  But I can't find the confusion.

"whitespace" or "raw" matched following mails: 
(match in base64 part is eliminated.)

<3c6971c5_2 / spamkiller.newsgroups.com>: ANN: REXML 1.2.6
<20020515150244.GA15304 / certicom.com>: How to eliminate whitespace-only text nodes?
<200205271049.47520.ser / germane-software.com>: ANN: REXML 2.3.4 and 2.2.2
<200301211722.h0LHMSAl006434 / mail531.nifty.com>: printing empty elements
<200301211806.h0LI6JAl028774 / mail531.nifty.com>: printing empty elements
<200301212053.31553.ser / germane-software.com>: Re: printing empty elements
<200301221536.h0MFaibn008669 / mail531.nifty.com>: Re: printing empty elements
<3E2ECE85.2020007 / blahr.com>: Re: printing empty elements
<200302170214.51369.ser / germane-software.com>: ANN: REXML 2.5.4

<20020504004149.GA32239 / certicom.com>: Any more samples/better docs around?
<200306121906.51047.ser / germane-software.com>: ANN: REXML 2.7.0 (3.0b)
<3F7C2DAD.4050706 / curnomatic.dk>: Re: max size of document for tree parser?
<20031002162938.GA20338 / mail.inet.hr>: Re: max size of document for tree parser?
<200310060746.50691.ser / germane-software.com>: Re: max size of document for tree parser?
<20031006141751.GA3578 / mail.inet.hr>: Re: max size of document for tree parser?
<1067006463.2463.4.camel / eagle>: problem with indentation

But I still can't find the confusion.

Most of the mails is not related to hash argument.

I think the mail closest to the issue is <20020515150244.GA15304 / certicom.com>.
But I don't think the author confused.

> I have a better idea:  how about you do whatever you want to do with your API? 

Yes.  I'll do.  However I don't like confusing API.

> I don't need to prove to you that this is troublesome because I don't care 
> what the API for open-uri looks like.  I was providing advice based on my 
> experience, and if you choose to ignore the advice, it doesn't affect me.  
> It'll affect your users, and it'll affect *you*.  Its your API, and seeing as 
> I don't use the library, I don't have a vested interest in how it looks.

Yes.  I interested your advice because it may affect me.  But I can't
make decision that I should take your advice or not until I know why
hash argument is confusing.  So I'm asking why.

> The real problem with APIs for libraries is that once you define them, they're 
> very, very painful to change.  If you decide in the future, like I did with 
> REXML, that hashes were the wrong decision, too bad.  The only option is to 
> keep them (legacy code... auugh!) or break all of the applications that use 
> your library.  The second option really is a last resort.  This is the *only* 
> reason why REXML still has hash parameters in its API.
> 
> Note that this applies not only to issues like hashmap parameters, but to any 
> other API decision.  There are a few API decisions that I regret about REXML.  
> I think its an occupational hazard when authoring libraries.

Agreed.  I saw some very painful cases: CGI#[], net/http's version
selection, etc.

But, at present, I feel that I don't regret that open-uri use hash argument.
-- 
Tanaka Akira