On Sun, Nov 16, 2008 at 1:53 PM, Piotr Dobrogost <curlpp_at_2008.autoera.pl>wrote:

> Jean-Philippe Barette-LaPierre wrote:
> > sorry, I made a typo doing it. Take two:
> > std::string address = "http://example.com <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.
>
> Agree.
>
> > 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);
>
> Bingo. That's what I had in mind.
> I see it's often better to just show some code than trying to explain ideas
> :)
>
> > 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.
>
> Agree.
> We should allow both kinds of set and both of setOpt. What do you think?

Alright with me. However, if we do so, we should explain in the
documentation the presence of "set" AND "setOpt" functions.

>
>
> 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