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?
Regards
Piotr Dobrogost
_______________________________________________
cURLpp mailing list
[email protected]
http://www.rrette.com/mailman/listinfo/curlpp
