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
