Curl support RFC

[Jonas Drewsen]

On 13/03/11 00.28, Jonathan M Davis wrote:
> On Saturday 12 March 2011 13:51:37 Jonas Drewsen wrote:
>> On 12/03/11 20.44, Jesse Phillips wrote:
>>> Jonas Drewsen Wrote:
>>>> On 11/03/11 22.21, Jesse Phillips wrote:
>>>>> I'll make some comments on the API. Do we have to choose Http/Ftp...?
>>>>> The URI already contains this, I could see being able to specifically
>>>>> request one or the other for performance or so www.google.com works.
>>>>
>>>> That is a good question.
>>>>
>>>> The problem with creating a grand unified Curl class that does it all is
>>>> that each protocol supports different things ie. http supports cookie
>>>> handling and http redirection, ftp supports passive/active mode and dir
>>>> listings and so on.
>>>>
>>>> I think it would confuse the user of the API if e.g. he were allowed to
>>>> set cookies on his ftp request.
>>>>
>>>> The protocols supported (Http, Ftp,... classes) do have a base class
>>>> Protocol that implements common things like timouts etc.
>>>
>>> Ah. I guess I was just thinking about if you want to download some file,
>>> you don't really care where you are getting it from you just have the
>>> URL and are read to go.
>>
>> There should definitely be a simple method based only on an url. I'll
>> put that in.
>>
>>>>> And what about properties? They tend to be very nice instead of set
>>>>> methods. examples below.
>>>>
>>>> Actually I thought off this and went the usual C++ way of _not_ using
>>>> public properties but use accessor methods. Is public properties
>>>> accepted as "the D way" and if so what about the usual reasons about why
>>>> you should use accessor methods (like encapsulation and tolerance to
>>>> future changes to the API)?
>>>>
>>>> I do like the shorter onHeader/onContent much better though :)
>>>
>>> D was originally very friendly with properties. Your could can at this
>>> moment be written:
>>>
>>> http.setReceiveHeaderCallback = (string key, string value) {
>>>
>>>           writeln(key ~ ":" ~ value);
>>>
>>> };
>>>
>>> But is going to be deprecated for the use of the @property attribute. You
>>> are probably aware of properties in C#, so yes D is fine with public
>>> fields and functions that look like public fields.
>>
>> Just tried the property stuff out but it seems a bit inconsistent. Maybe
>> someone can enlighten me:
>>
>> import std.stdio;
>>
>> alias void delegate() deleg;
>>
>> class T {
>>     private deleg tvalue;
>>     @property void prop(deleg dg) {
>>       tvalue = dg;
>>     }
>>     @property deleg prop() {
>>       return tvalue;
>>     }
>> }
>>
>> void main(string[] args) {
>>     T t = new T;
>>     t.prop = { writeln("fda"); };
>>
>>     // Seems a bit odd that assigning to a temporary (tvalue) suddently
>>     // changes the behaviour.
>>     auto tvalue = t.prop;
>>     tvalue();     // Works as expected by printing fda
>>     t.prop();     // Just returns the delegate!
>>
>>     // Shouldn't the @property attribute ensure that no () is needed
>>     // when using the property
>>     t.prop()(); // Works
>> }
>
> @property doesn't currently enforce much of anything. Things are in a transitory
> state with regards to property. Originally, there was no such thing as @property
> and any function which had no parameters and returned a value could be used as a
> getter and any function which returned nothing and took a single argument could
> be used as a setter. It was decided to make it more restrictive, so @property
> was added. Eventually, you will _only_ be able to use such functions as property
> functions if they are marked with @property, and you will _have_ to call them
> with the property syntax and will _not_ be able to call non-property functions
> with the property syntax. However, at the moment, the compiler doesn't enforce
> that. It will eventually, but there are several bugs with regards to property
> functions (they mostly work, but you found one of the cases where they don't),
> and it probably wouldn't be a good idea to enforce it until more of those bugs
> have been fixed.
>
> - Jonathan M Davis

Okey... nice to hear that this is coming up.

Thanks again!
/Jonas