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
