Curl support RFC

Jonathan M Davis jmdavisProg at gmx.com
Sat Mar 12 15:28:58 PST 2011


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


More information about the Digitalmars-d mailing list