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); 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 > cURLpp@rrette.com > http://www.rrette.com/mailman/listinfo/curlpp >
_______________________________________________ cURLpp mailing list cURLpp@rrette.com http://www.rrette.com/mailman/listinfo/curlpp
