gk at ninebynine.org
Fri Oct 22 07:19:50 EDT 2004
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.
or suchlike. What's most Haskell-ish here?
> > * Should we deprecate parseURI, scheme, authority, path, query,
> > and fragment?
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 .
More information about the Cvs-libraries