How do you suppose to solve the typeof(uri) != 'string' issue? I guess
that's really a general issue with lacking "is a" functionality in a
class-based system. You could have it identify itself as a string in
$type(uri) but that could lead to confusion among extensions.

To me, the current URI implementation over string doesn't really
provide much more functionality than if you just extended all strings
with it. Such as 'string'.getURIData();

For more complex interactions I'd prefer to have an object to
manipulate that doesn't need to be re-parsed all the time.

I'd like to point out again that even a class-based URI can be used in
all native capacities such as XMLHTTPRequest, as a href and
window.location.

window.location = new Uri('...');

This is valid even though Uri is class-based. Even when "inheriting"
from string doesn't make it less of an object. Even concatenation
works the same.

The question is only whether or not it should keep the substr, trim,
replace, and all other extended string methods.

IMO, the best way would be to have String extensions (not inheritance)
in String.URL in combination with an extensible "proper" URI class.

That way there isn't going to be any confusion in consumers of the
objects. A string is $type(uri) == 'string' and all string
functionality can be expected to have the same effects.

Maybe I just haven't come across the scenarios where it would be
useful. Let's say for example that I wanted to append a filename to
the end of a URI.

I could do:
a.href = new Uri('http://domain/') + 'filename.html';

I can do that whether it extends string or not. But to be sure that I
handle the Uri correctly I'd prefer to do that with a proper method
such as:
a.href = new Uri('http://domain/').setFilename('filename.html');

That way I'm sure that I don't miss a trailing slash or some other URL
format quirk. To me, the purpose of a URI class is so that we DON'T
have to deal with string manipulation.

Aaron, could you perhaps fill me in on a few concrete URI manipulation
scenarios where it would be more beneficial to have string
functionality?


On Mar 12, 8:06 pm, Thomas Aylott / subtleGradient
<[email protected]> wrote:
> I think this is best.
> Let's rename URI -> URL (or even String.URL ideally) and we can spend
> some time doing a "proper" URI class also.
>
> — Thomas Aylott / SubtleGradient.com
>
> nutron wrote:
>
> […]> we need to have this URL thing which is a subclass of string, but
> > maybe a URI class that uses or extends it. I still think that we could
> > easily subclass URI to allow us to subclass other types of strings
> > (mailto for example) in the same manner.
>
> […]

Reply via email to