On Sun, Nov 16, 2008 at 12:43 PM, Jean-Philippe Barette-LaPierre <
jpbarrette_at_gmail.com> wrote:

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

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