-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add RelURI, AbsURI #37
Comments
OK, so there are two reasons why the uriAuthority field currently has to be a Maybe. (a) Because we support parsing both URIs and URI references through the same interface, I agree with you that it might be better if "URI references" (relative URIs) were a different type, if only to type-check against combining two "non-relative" URIs. We can consider adding new interfaces to support that idea, but we are stuck with supporting the existing types. We can look at some concrete proposals together for an additional set of types and functions; I'm a little skeptical that it doesn't wind up being a complete fork of the whole interface, but let's explore it. If the real goal is to get to a place where you have an "absolute" URI type that doesn't allow |
IMHO good is t dispense with little blood. For example. URI now is type for rel and abs URIs. It is reflected in the name. If somebody needs more strict it can use 2 additional types: AbsURI, RelURI. How to keep different APIs (1st for URI, 2nd for RelURI/AbsURI) - I don't know. In OOP I can imagine solution: each AbsURI and RelURI are still URI, so old API can be for backward compatibility (and to work with URI as now, with AbsURI/RelURI too - they are URIs too) and to have new, more strict API, where some run-time checks will moved to types restrictions. Modules may be: |
The idea of strongly typing https://github.com/haskell/network-uri/tree/strong It takes the form of a second module, Network.URI.Strong, that differentiates between an "absolute" type of URI reference, (a) the relativeTo and relativeFrom functions have more precise types, If this project were to move forward, it would be necessary to make the new module fully documented and tested. It becomes a new, parallel, interface that needs to be perpetually kept in sync with the traditional one. I'm not too keen on that, but I offer it up for comment. (By the way, the word "absolute" is used in the RFC in a slightly surprising way: It requires that there be no fragment component (as well as the more expected requirement that the scheme is specified, which captures the intuition that an absolute URI is "rooted" and "not relative to" some other URI). In the Network.URI module, that sense of "absolute" is used in some places, but the |
Good news, super! RFCs "absolute", maybe, is more relevant from content point of view: relative URL in this case refers to something inside itself (serving a part vs. serving a whole)... So, I'm not sure what will be better terminology is this case, if RFC already reserves "absolute" word :) |
I came here to ask for the same thing 🙂 Another option is to provide relative/absolute like how the path package does it, so we'd have |
Here's a sketch... {-# LANGUAGE EmptyDataDecls #-}
module Network.URI.Strong
( URI
, Abs, Rel
, getURI
, parseRelativeURI
, parseAbsoluteURI
, (</>)
)
where
import Data.Typeable
import qualified Network.URI as U
data Abs deriving (Typeable)
data Rel deriving (Typeable)
newtype URI t = URI { getURI :: U.URI }
deriving (Show, Eq, Ord)
parseRelativeURI :: String -> Maybe (URI Rel)
parseRelativeURI = fmap URI . U.parseRelativeReference
parseAbsoluteURI :: String -> Maybe (URI Abs)
parseAbsoluteURI = fmap URI . U.parseAbsoluteURI
(</>) :: URI t -> URI Rel -> URI t
(URI base) </> (URI rel) = URI (rel `U.relativeTo` base) This would be sufficient for my use (since you can access the scheme etc by calling |
UriAuth is under Maybe - as I understood due to wrap relative/absolute URIs under one type. If I have abs. URI I will propagate those Maybe anywhere. Better may be to distinguish abs. and rel. URIs - with different types. When I parse rel. URI (reference) - no any auth. In this case combining URIs will be checked on type level: rel+rel, abs+rel, but no abs+abs.
The text was updated successfully, but these errors were encountered: