On Sun, Nov 16, 2008 at 6:45 AM, Piotr Dobrogost <curlpp_at_2008.autoera.pl>wrote:
> Jean
>
> Jean-Philippe Barette-LaPierre wrote:
> >
> >
> > On Fri, Nov 14, 2008 at 4:12 PM, Piotr Dobrogost <curlpp_at_2008.autoera.pl
> > <mailto:curlpp_at_2008.autoera.pl>> 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_at_rrette.com
> http://www.rrette.com/mailman/listinfo/curlpp
>
_______________________________________________
cURLpp mailing list
cURLpp_at_rrette.com
http://www.rrette.com/mailman/listinfo/curlpp
Received on 2008-11-16