On Sun, Nov 16, 2008 at 12:43 PM, Jean-Philippe Barette-LaPierre < [EMAIL PROTECTED]> wrote:
> > > On Sun, Nov 16, 2008 at 6:45 AM, Piotr Dobrogost <[EMAIL PROTECTED]>wrote: > >> Jean >> >> Jean-Philippe Barette-LaPierre wrote: >> > >> > >> > On Fri, Nov 14, 2008 at 4:12 PM, Piotr Dobrogost < >> [EMAIL PROTECTED] >> > <mailto:[EMAIL PROTECTED]>> wrote: >> > >> > Jean >> > >> > Using Easy::setOpt is not as convenient as it should be. >> > >> > Now we have >> > >> > std::string address = "http://example.com"; >> > // Setting the URL to retrive. >> > request.setOpt(new cURLpp::Options::Url(address)); >> > >> > Could we do better? >> > >> > std::string url = "http://example.com"; >> > // Setting the URL to retrive. >> > request.set<url>(address); >> > >> > >> > Well... No... The thing is setOpt wouldn't be able to distinguish >> > between different "string" options (Url, Proxy, Interface, etc). >> However: >> >> I know you use this scheme to be able to make this distinction. The point >> is that passing an option type as template's argument to set<typename T> >> gives the same information like passing an option type as a type of the >> argument of function. >> The question is what does wrapping arguments of setOpt in the Options::X >> type give us? Later on it's convenient to have all options' types be derived >> from one base class (OptionBase) to treat them polymorphically in containers >> and alghorithms . But in the moment of setting an option using setOpt we >> don't really need this and we shouldn't force users to wrap all these values >> only to give them to setOpt method. >> What do you think? > > > So, if I take your previous example: > > std::string url = "http://example.com"; > > // Setting the URL to retrive. > > request.set<url>(address); > > and I fix the typo: > > request.set<Url>(address); > sorry, I made a typo doing it. Take two: std::string address = "http://example.com"; // Setting the URL to retrive. request.set<cURLpp::Options::Url>(address); > > > Then, I would say that I don't see any argument against. However, I > wouldn't remove the former > method, since people already had done some coding using it. > > So, we could add something like this: > > template< OptionType > > void setOpt(T::ParamValue value) > { > setOpt(new Option(value)); > } > > then, we would be able to call > request.setOpt<cURLpp::Options::Url>(address); > > Now, if you really want "set" instead of setOpt, I don't have any problems > with it, but with one restriction: > - "set" should be only an alias to "setOpt". > Again, code has already been done with setOpt, and I don't want > a different set of functionalities for set or setOpt. setOpt is more in > line > with libcURL and I want to keep its name scheme. > > > >> >> >> Regards >> Piotr Dobrogost >> _______________________________________________ >> cURLpp mailing list >> [email protected] >> http://www.rrette.com/mailman/listinfo/curlpp >> > >
_______________________________________________ cURLpp mailing list [email protected] http://www.rrette.com/mailman/listinfo/curlpp
