Network.URI changes

[Graham Klyne]

At 09:01 22/10/04 +0100, Simon Marlow wrote:
>[ adding Graham to CC list, just in case you're not on cvs-libraries ]

Thanks.  (I'm not on that list.)

And thanks, Sven, for taking the trouble to review this.

>On 21 October 2004 17:52, Sven Panne wrote:
>
> > Two small remarks/questions about the new Network.URI:
> >
> >     * I'm a little bit unhappy with the current spelling "fooUri" vs.
> >       "fooURI", both are used randomly in the module. I'd vote for a
> >       consistent usage of "fooURI", this is consistent with the rest
> >       of the hierarchical libs. An implication of this would be the
> >       need to invent a new name for "parseUri", because "parseURI" is
> > already taken by an old function.
>
>Our general policy is to use the capitalised version of acronyms (ie.
>URI rather than Uri), but there are many exceptions to this in the
>libraries already.  But sometimes the capitalised version looks ugly,
>especially when it occurs in the middle of an identifier.
>
>I'm inclined to agree with Sven here.  Graham?

I think I agree, too.  This bothered me a little as I was developing the 
code, and (as noted) I didn't really settle on a single consistent 
position.  I think my feeling is that because Haskell gives some 
significance to case in names, it's sometimes awkward and/or ugly to try 
and impose an uppercasing-of-acronyms convention.

This would be a good time to make changes for consistency, and I'm content 
to update my code as needed.

>perhaps stringToURI instead of parseURI?

So the four parse*Uri* functions would become stringTo*URI* ?

That works for me.  Almost.  The problem is that the different names refer 
to variations in the string content, not differences in the final value 
(otherwise a Read instance could be used, right?).  I think a <verb>*URI* 
here is more meaningful.  e.g.
    readURIReference
    decodeURIReference
or suchlike.  What's most Haskell-ish here?

> >     * Should we deprecate parseURI, scheme, authority, path, query,
> > and fragment?
>
>Yes.

That's a plan I like.  (I assume we'd keep them for a release or two while 
software get's converted?)  Any deprecation note should make clear that the 
new components have different functionality (including the '//', '/', '?', 
'#' characters, etc.)

While considering this issue, would it be appropriate to consider 
interfaces for updating URI components that isolate calling programs from 
the internal data type components?  That coupling was a (small) problem for 
me in developing this new version.

...

Another area that I think might possibly be improved is the interface for 
suppressing authority passwords in the string form of a URI.  I don't know, 
what do you think?  The current interface is thus:
[[
-- |URI as instance of Show.  Note that for security reasons, the default
--  behaviour is to suppress any userinfo field (see RFC2396bis, section 7.5).
--  This can be overridden by using uriToString directly with first
--  argument @id at .
]]

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact