/.../ So rather than having a property, I think we should have a decode function, to which the strings can be passed after the user code separates them on "/" or whatever URI syntax still remains in the string.
Sure, why not? Maybe it could take a charset too to know how to handle the 8-bit chars.
Yes, that was exactly what I was suggesting higher up in the text. :-)
If the extra encoding gets likewise optional, it both gets more symmetric and works in the use case I've been trying to describe.
True, right now no characters are encoded by the constructor, so it would indeed be more symmetrical to add this functionality to a function like quote().
By the way, is the someone who knows why 7.7 has two encode functions (http_encode and quote) whereas 7.6 only has one (quote)?
(In retrospect, it would be better if the URI class actually parsed all the URI syntax, rather than returning something half parsed. That would mean path being array(string) instead of string. /.../
I'm not so sure; a path on array form gets unbearably cumbersome to handle compared to the standard string form. An alternative is to only decode as much as possible, i.e. leave only %2F (for "/") and %25 (for "%"). That's a consistent encoding too that can be decoded the same way after path splitting, if the user wants to. It's a bit unfortunate that the "%" chars have to left encoded too, though.
The thing is that decoding is not a question of whether the use wants to decode. The user has to decode to get something useful. Unless the class does it for him, of course. I don't see that a partial decode would be particularly useful to anyone.