There're no setters, and I agree getters are not strictly necessary. But if you want to extend URI, and you want to pass it to a method that expects a URI parameter, in the absense of a cross browser __defineGetter__, you can always override the getter. This is an edge case though.
On Tue, Mar 10, 2009 at 4:07 PM, Sebastian Markbåge <[email protected]>wrote: > > Do we really need getters and setters at all though? If the parts are > split in the constructor and methods you really don't need getters and > setters for the parts. Then the API methods can concern themselves > only with combining/merging/formatting the Uri. I think it would > simplify the class and the API somewhat. I know get/set is best- > practise around mootools circles already though. > > On Mar 10, 6:47 pm, Guillermo Rauch <[email protected]> wrote: > > Yea the thing is we need to subclass URI to something like > > URI.JavascriptOtherwise > > it doesn't make sense to fill URI with methods like getScript()... and a > > method for every possible part of each scheme. And still, URI.Javascript > > would get a bunch of useless methods like getPort. > > > > To me this is easily solved by a generic get() getter. > > > > > > > > On Tue, Mar 10, 2009 at 3:33 PM, nutron <[email protected]> wrote: > > > It's worth noting that the URI stuff extends A string - not all > strings, > > > but URI itself has a prototype and that you can implement as many > methods as > > > you like. So we could have a URI.Extras.js or URI.Extended.js or > whatever > > > that just implements new methods on URI. > > > URI.implement({ > > > ///fooo > > > }); > > > > > This works just fine. The only catch is that the combine method, which > > > references all the parts in the reg-ex explicitly, isn't very > extensible. > > > We'd need to revisit how this method works to be more generic and > > > extensible. > > > > > On Tue, Mar 10, 2009 at 9:25 AM, Guillermo Rauch (via Nabble) < > > > ml-user%2b56054-417756...@...< > http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2456699&i=0> > > > > wrote: > > > > > On Tue, Mar 10, 2009 at 3:19 PM, Sebastian Markbåge <sebast...@...< > http://n2.nabble.com/user/SendEmail.jtp?type=node&node=2456644&i=0> > > >> > wrote: > > > > >> Even though there are many different forms of schemes, the API can > > >>> easily be applied to many of them. The ones with special purposes > > >>> could easily be extended with the necessary APIs. Both the Java > > >>> and .NET frameworks has common Uri classes to work with several > > >>> different schemes with a common API. > > > > >> Yes. I was saying the More URI didn't have a flexible API, but yours > can > > >> accomodate to any scheme. > > > > >> I'll make some drafts on a version which extends the String native. > > > > >> Please take a look at the current URI in GitHub. I suggest you work on > > >> defining a URI.Schemes there, and replace the .implement({}) of the > part > > >> getters with a general get() method. > > > > >> -- > > >> Guillermo Rauch > > >>http://devthought.com > > > > > The MooTools Tutorial:www.mootorial.comClientcide:www.clientcide.com > > > > > ------------------------------ > > > View this message in context: Re: Uri class< > http://n2.nabble.com/Uri-class-tp2456119p2456699.html> > > > Sent from the MooTools Users mailing list archive< > http://n2.nabble.com/MooTools-Users-f660466.html>at Nabble.com. > > > > -- > > Guillermo Rauchhttp://devthought.com -- Guillermo Rauch http://devthought.com
