- An URI is a string, despite its special arrangement of characters and
   set of rules.
   - The toURI() / toString() API is definitely interesting if we want to
   separate it into its own new class.
   - It's true valueOf will get the string, but how many functions within
   your code will check for that *now* ? How about 3rd party code ? You'd
   really need to run toString() everytime you're going to pass it. valueOf is
   meant to return a primitive value, so a toString method is better, btw.
   - It's also true that the value of inheriting the native string methods
   is next to null.

On Tue, Mar 10, 2009 at 8:05 PM, Sebastian Markbåge
<[email protected]>wrote:

>
> I'm still not fully convinced that it should extend String. There are
> a couple of issues I have with it...
>
> - Native APIs that require an Uri all make use of valueOf() and
> therefore it is still possible to use an object for window.location =
> uri; window.location.href = uri; aswell as XMLHTTPRequest.
> - The only issue with not extending String is when you use the URI for
> another API which expects a string. But that Uri should call valueOf()
> or at least test typeof() and therefore it's a problem on that end and
> not a problem in the URI object. That is why we have valueOf() isn't
> it?
> - typeof(...) and $type(...) will still NOT return 'string' and
> therefore if another API uses typeof(...) checks or Array.link, it
> won't work anyway.
> - If, String is extended with methods with the same name as the ones
> in URI. It can lead to confusion in classes that are expecting a
> String with those extensions yet receives an object where those
> methods have a different meaning. For example: 'Text'.parse(function)
> vs. new Uri('http://www.mootools.net/').parse() for example. Possibly
> an edge case but I'd still say it's an iffy architecture.
> - Some of the verbs of String methods are dubious at best if you use
> them in an Uri context. Such as: trim, clean, test, slice, toSource
> (FF) etc...
>
> It's tempting to extend the natives but in an object-oriented sense,
> an URI isn't really just a string. Just like a string isn't just an
> array of characters. It's it's own type with it's own meaning. I think
> it could get messy quite quickly if it's going to be extended.
>
> If a String is a must, I think it would be better to let those
> features be pure extensions on String. For example:
> var uri = 'http://www.mootools.net/example?test';
> uri.getUriQuery(); // returns '?test'
> uri.getUriPart('hostname'); // returns 'www.mootools.net'
> uri.toRelativeUri('http://www.mootools.net/'); // returns 'example?
> test'
>
> But I think it would be best to have extendable URI objects and let
> valueOf() do it's job. One could easily change them back and forth:
> var uri = 'http://www.mootools.net'.asUri();
> uri.get('hostname'); // returns 'www.mootools.net'
> uri.valueOf().substr(0, 21).getUriPart('hostname'); // returns
> 'www.mootools.n'




-- 
Guillermo Rauch
http://devthought.com

Reply via email to