Curl support RFC

Jonas Drewsen jdrewsen at nospam.com
Sat Mar 12 13:51:37 PST 2011


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
}

/Jonas




> Otherwise this looks really good and I do hope to see it in Phobos.
>



More information about the Digitalmars-d mailing list