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