Yes. Since you objected to having a separate Standards.IRI I'm talking about what's required to merge that functionality into the current class. But by now I think this functionality fits well into Standards.URI since it doesn't do any implicit encoding or decoding.
My suggestion was not to merge the functionality, but simply to allow the constructor to be called with an IRI, and in that case convert it to the equivalent URI, just like Gmp.mpq() can be called with a bignum, converting it to the equivalent fraction. IMO, this should covert most real use-cases.
Um, weren't we discussing how decoding everything except %25 and %2f was supposed to make the user happy somehow? In that case %5c would be decoded into , no?
Right, but as opposed to "/" there can never be any unencoded "" with metameaning that it can be ambiguous with.
No, but a "" can be ambigous with a "/", so you need to check for it before you use the path as a local filename. So we have the following scenarios:
1) path is fully encoded:
* Need to check for %2f and %2F before decoding, and \ after decoding (or %2c and %2C before decoding)
2) path is decoded except for %25 and %2f:
* Need to check for %2f, %2F and \ (and you'll get the wrong result if %25 is present)
3) path is array of fully decoded components
* Need to check for / and .