Sure, could be a new native but if it's a new native it's still not compatible with consumers only expecting string.
And yes, I agree, capital URI or URL should be the naming convention to go for. innerHTML and baseURI are two other existing examples of acronyms. The only reason I used Uri in my version and refer to it as such is because it could still co-exist with the other variant and the convention around other server-side frameworks I use was Uri. On Mar 12, 11:42 pm, ibolmo <[email protected]> wrote: > Oh, and please no Uri Url or anything of the sort. They're both > acronyms: URI, URL ftw > > On Mar 12, 2:34 pm, Sebastian Markbåge <[email protected]> wrote: > > > 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. > > > > […]
