If you need $type('object') == 'uri' then maybe URI should be a
Native.
var URI = new Native({
name: 'URI',
initialize: function(){...}
});
var object = new URI('...');
URI.type(object) //true
$type(object) //uri
Olmo
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.
>
> > […]
