window.Location.prototype does implement some methods that are tightly coupled to the current location so I guess that's not a great idea. I'm all for dropping it.
I'm also on-board with an abstract URI base class that doesn't inherit String. I would love it if it's inheritors could be designed not to violated the substitution principle and be immutable. On 15 Mar, 02:48, Sebastian Markbåge <[email protected]> wrote: > Yea, but window.Location.prototype is different from window.location. > So if it is inherited from window.Location it's the type, not the > object describing the current window's location. > > The type has for example a resolveURL() method to resolve relative > URIs. Unfortunately it is resolved to a String. > > I'm not married to the idea. I'm just saying, there's a type contract > in place if we would like to extend it. > > On 15 Mar, 02:32, Guillermo Rauch <[email protected]> wrote: > > > On Sat, Mar 14, 2009 at 11:25 PM, Sebastian Markbåge > > <[email protected]>wrote: > > > > So something like: new Element('img', { src: new URI.GoogleChart > > > (...) }); > > > > Interesting. You don't need it to extend string to do that though. But > > > it does open up some interesting extension possiblities. > > > I'm not bringing the String vs Class argument again. I'm just saying that > > URIs should not be bound to the window Location. > > > -- > > Guillermo Rauchhttp://devthought.com
