Yea, I like that it extends the String native. There's really nothing preventing us from doing the same in my approach. Setters and getters are possibly the way to go since setting a part without changing the full href results in an invalid state. Another alternative would be to storing only the parts and rebuilding the full href in a function.
What I like about the API in my approach is the close resemblance to the ILocation interface, defined by the W3C. Extending String could possibly lead to confusion. However, the same could be said about a custom Class. There are bound to be issues with window.location = uri; problems. Even though there are many different forms of schemes, the API can easily be applied to many of them. The ones with special purposes could easily be extended with the necessary APIs. Both the Java and .NET frameworks has common Uri classes to work with several different schemes with a common API. I'll make some drafts on a version which extends the String native.
