Spiritd updated.
FWIW, I've updated spiritd to work w/ dmd 2.058. I've also moved the code to GitHub: https://github.com/div0/spiritd -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk
Re: unzip parallel, 3x faster than 7zip
On 4/5/2012 6:53 PM, Jay Norwood wrote: I'm curious why win7 is such a dog when removing directories. I see a lot of disk read activity going on which seems to dominate the delete time. This doesn't make any sense to me unless there is some file caching being triggered on files being deleted. I don't see any virus checker app being triggered ... it all seems to be system read activity. Maybe I'll try non cached flags, write truncate to 0 length before deleting and see if that results in faster execution when the files are deleted... If you delete a directory containing several hundred thousand directories (each with 4-5 files inside, don't ask), you can see windows freeze for long periods (10+seconds) of time until it is finished, which affects everything up to and including the audio mixing (it starts looping etc).
Re: unzip parallel, 3x faster than 7zip
On Friday, 6 April 2012 at 14:55:14 UTC, Sean Cavanaugh wrote: If you delete a directory containing several hundred thousand directories (each with 4-5 files inside, don't ask), you can see windows freeze for long periods (10+seconds) of time until it is finished, which affects everything up to and including the audio mixing (it starts looping etc). Yeah, I saw posts by people doing video complaining about such things. One good suggestion was to create may small volumes for separate projects and just do a fast format on them rather than trying to delete folders. I got procmon to see what is going on. Win7 has doing indexing and thumbnails, and there was some virus checker going on, but you can get rid of those. Still, most of the problem just boils down to the duration of the delete on close being proportional to the size of the file, and apparently related to the access times of the disk. I sometimes see .25 sec duration for a single file during the close of the delete operations on the hard drive. I've been using an intel 510 series 120GB drive for recording concerts. It is hooked up with an ineo usb3 adaptor to the front panel port of an rme ufx recorder. The laptop is just used as a controller ... the ufx does all the mixing and recording to the hard drive.
Re: D Conference 2012
On 4/4/2012 7:22 AM, Steven Schveighoffer wrote: On Tue, 27 Mar 2012 17:29:08 -0400, Walter Bright newshou...@digitalmars.com wrote: The web site is up now: http://www.astoriaseminar.com See you all there! Any chance we can search for treasure while there? I'm sure there's plenty of pirate treasure buried along the shore! I wish it was closer, and/or I was doing less vacation this year so I could go :(
Re: unzip parallel, 3x faster than 7zip
Am 05.04.2012 19:04, schrieb Timon Gehr: On 04/05/2012 06:37 PM, dennis luehring wrote: Am 05.04.2012 16:04, schrieb Jay Norwood: I uploaded a parallel unzip here, and the main in the examples folder. Testing on my ssd drive, unzips a 2GB directory structure in 17.5 secs. 7zip took 55 secs on the same file. it makes no sense to benchmark different algorithm zip-7zip compare only unzip and parallel unzip - nothing else makes sense I think he is talking about 7zip the standalone software, not 7zip the compression algorithm. 7zip took 55 secs _on the same file_. that is ok but he still compares different implementations
Re: unzip parallel, 3x faster than 7zip
Am 06.04.2012 01:53, schrieb Jay Norwood: I'm curious why win7 is such a dog when removing directories. I see a lot of disk read activity going on which seems to dominate the delete time. try windows safe-mode (without network :} - your virus scanner is disabled), press F8 before windows start - thats seems to remove many strange pauses,blockings etc. - still no idea why, but a good testenvironment
Re: IDE Support for D
On Fri, 06 Apr 2012 06:20:27 +0200 Maxim ma...@maxim-fomin.ru wrote: I prefer to use Codeblocks and i guess Visual D would be good on Windows. Has D support for Codeblocks improved somewhat recently? Otherwise, I'm considering to use Geany and/or buy SublimeText2. Sincerely, Gour -- Even the intelligent are bewildered in determining what is action and what is inaction. Now I shall explain to you what action is, knowing which you shall be liberated from all misfortune. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: Custom attributes (again)
On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. I was thinking of something along the lines of what has been proposed here earlier: @attr(identifier = expression) as a storage class, like: @attr(foo = bar + 1) int x; and then: __traits(hasAttribute, x, foo) would return true, and: __traits(getAttribute, x, foo) would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration. The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs. You could also omit the expression, and just have: @attr(bar) int y;
Re: Custom attributes (again)
On Friday, 6 April 2012 at 06:47:56 UTC, Walter Bright wrote: On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. I was thinking of something along the lines of what has been proposed here earlier: @attr(identifier = expression) as a storage class, like: @attr(foo = bar + 1) int x; and then: __traits(hasAttribute, x, foo) would return true, and: __traits(getAttribute, x, foo) would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration. The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs. You could also omit the expression, and just have: @attr(bar) int y; I like it for the most part. One thing I'd like to see is placing multiple attributes both by using multiple @attr()'s, and by using comma separated identifier/expression pairs inside a single @attr. In other words, the following two declarations would be identical. @attr(Description = Blah, ReadOnly) int ID; @attr(Description = Blah) @attr(ReadOnly) int ID; My only concerns: First, @attr() is a little verbose / not exactly pretty. This isn't really a big issue, since attributes aren't exactly piled on and it makes it easy to tell what's going on. It is a little uglier than in other languages however. Secondly, from what I can tell it's an arbitrary key value combo. What would happen if you're working on a larger project and two unrelated libraries try to use the same attribute name to mean different things? With the module system this issue doesn't exist since you have to import it and can selectively/privately do so, but from what I understand the method you're proposing doesn't declare the attribute itself at all. Am I just misunderstanding this part?
Re: Custom attributes (again)
On Friday, 6 April 2012 at 06:47:56 UTC, Walter Bright wrote: On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. I was thinking of something along the lines of what has been proposed here earlier: @attr(identifier = expression) as a storage class, like: @attr(foo = bar + 1) int x; and then: __traits(hasAttribute, x, foo) would return true, and: __traits(getAttribute, x, foo) would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration. The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs. You could also omit the expression, and just have: @attr(bar) int y; I like it. Perhaps @attr(bar) could be equivalent to @attr(bar = true) so you don't get any weird failure state for __traits(getAttribute?
Re: Custom attributes (again)
On 06-04-2012 08:47, Walter Bright wrote: On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. I was thinking of something along the lines of what has been proposed here earlier: @attr(identifier = expression) as a storage class, like: @attr(foo = bar + 1) int x; and then: __traits(hasAttribute, x, foo) would return true, and: __traits(getAttribute, x, foo) would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration. The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs. You could also omit the expression, and just have: @attr(bar) int y; I think this is mostly reasonable. I assume that it would be possible to use the comma operator to attach multiple values to it? I.e.: @attr(foo = bar, baz) int x; My only other concern is what Kapps pointed out about larger projects and overlapping attribute names. -- - Alex
Re: Custom attributes (again)
On 4/6/2012 12:17 AM, Kapps wrote: I like it for the most part. One thing I'd like to see is placing multiple attributes both by using multiple @attr()'s, and by using comma separated identifier/expression pairs inside a single @attr. In other words, the following two declarations would be identical. @attr(Description = Blah, ReadOnly) int ID; @attr(Description = Blah) @attr(ReadOnly) int ID; Yes, that makes sense. My only concerns: First, @attr() is a little verbose / not exactly pretty. This isn't really a big issue, since attributes aren't exactly piled on and it makes it easy to tell what's going on. It is a little uglier than in other languages however. Could do: [[name = value]] I suppose. Not sure what's better. Secondly, from what I can tell it's an arbitrary key value combo. What would happen if you're working on a larger project and two unrelated libraries try to use the same attribute name to mean different things? With the module system this issue doesn't exist since you have to import it and can selectively/privately do so, but from what I understand the method you're proposing doesn't declare the attribute itself at all. Am I just misunderstanding this part? Good question. I don't have experience using attributes, so I don't know if this would be a problem. Keep in mind that the attribute lookup will only be done for a particular symbol, there won't be any global lookup.
Re: IDE Support for D
Mono-D is my go to IDE. It supports completion and debugging, and is cross-platform.
Re: Custom attributes (again)
On 06-04-2012 09:31, Bernard Helyer wrote: On Friday, 6 April 2012 at 06:47:56 UTC, Walter Bright wrote: On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. I was thinking of something along the lines of what has been proposed here earlier: @attr(identifier = expression) as a storage class, like: @attr(foo = bar + 1) int x; and then: __traits(hasAttribute, x, foo) would return true, and: __traits(getAttribute, x, foo) would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration. The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs. You could also omit the expression, and just have: @attr(bar) int y; I like it. Perhaps @attr(bar) could be equivalent to @attr(bar = true) so you don't get any weird failure state for __traits(getAttribute? While I understand the rationale, that seems a bit too magic... -- - Alex
Re: Custom attributes (again)
On 06-04-2012 09:32, Walter Bright wrote: On 4/6/2012 12:17 AM, Kapps wrote: I like it for the most part. One thing I'd like to see is placing multiple attributes both by using multiple @attr()'s, and by using comma separated identifier/expression pairs inside a single @attr. In other words, the following two declarations would be identical. @attr(Description = Blah, ReadOnly) int ID; @attr(Description = Blah) @attr(ReadOnly) int ID; Yes, that makes sense. My only concerns: First, @attr() is a little verbose / not exactly pretty. This isn't really a big issue, since attributes aren't exactly piled on and it makes it easy to tell what's going on. It is a little uglier than in other languages however. Could do: [[name = value]] I suppose. Not sure what's better. Secondly, from what I can tell it's an arbitrary key value combo. What would happen if you're working on a larger project and two unrelated libraries try to use the same attribute name to mean different things? With the module system this issue doesn't exist since you have to import it and can selectively/privately do so, but from what I understand the method you're proposing doesn't declare the attribute itself at all. Am I just misunderstanding this part? Good question. I don't have experience using attributes, so I don't know if this would be a problem. Keep in mind that the attribute lookup will only be done for a particular symbol, there won't be any global lookup. It actually can be a problem. In .NET land, there are many attributes across many projects (and even in the framework itself) with the same names. It turns out that regular namespace lookup rules alleviate this problem. -- - Alex
Re: Custom attributes (again)
On 4/6/2012 12:31 AM, Bernard Helyer wrote: I like it. Perhaps @attr(bar) could be equivalent to @attr(bar = true) so you don't get any weird failure state for __traits(getAttribute? That's what the hasAttribute is for.
Re: Custom attributes (again)
On 06-04-2012 08:47, Walter Bright wrote: On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. I was thinking of something along the lines of what has been proposed here earlier: @attr(identifier = expression) as a storage class, like: @attr(foo = bar + 1) int x; and then: __traits(hasAttribute, x, foo) would return true, and: __traits(getAttribute, x, foo) would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration. The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs. You could also omit the expression, and just have: @attr(bar) int y; Also, by storage class do you mean it will work only on fields? Attributes are very useful on many different kinds of declarations, so if that's the case, I think that would be too limiting. -- - Alex
Re: Custom attributes (again)
On 4/6/2012 12:42 AM, Alex Rønne Petersen wrote: Also, by storage class do you mean it will work only on fields? No. Storage classes work on fields, functions, and variables.
Re: Custom attributes (again)
On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote: It actually can be a problem. In .NET land, there are many attributes across many projects (and even in the framework itself) with the same names. It turns out that regular namespace lookup rules alleviate this problem. Perhaps a better scheme is: enum foo = 3; ... @attr(foo) int x; That way, foo will follow all the usual rules.
Re: Custom attributes (again)
On 06-04-2012 09:47, Walter Bright wrote: On 4/6/2012 12:42 AM, Alex Rønne Petersen wrote: Also, by storage class do you mean it will work only on fields? No. Storage classes work on fields, functions, and variables. What about type declarations? I think those ought to be supported too. E.g. it makes sense to mark an entire type as @attr(serializable) (or the inverse). -- - Alex
Re: IDE Support for D
On Fri, 06 Apr 2012 09:34:02 +0200 Bernard Helyer b.hel...@gmail.com wrote: Mono-D is my go to IDE. It supports completion and debugging, and is cross-platform. Yeah, it looks nice, but I've managed to stay mono-free on my machine. :-) Sincerely, Gour -- Bewildered by the modes of material nature, the ignorant fully engage themselves in material activities and become attached. But the wise should not unsettle them, although these duties are inferior due to the performers' lack of knowledge. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: Custom attributes (again)
On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote: What about type declarations? I think those ought to be supported too. E.g. it makes sense to mark an entire type as @attr(serializable) (or the inverse). That would make it a type constructor, not a storage class, which we talked about earlier in the thread. I refer you to that discussion.
Re: Custom attributes (again)
On 06-04-2012 09:54, Walter Bright wrote: On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote: What about type declarations? I think those ought to be supported too. E.g. it makes sense to mark an entire type as @attr(serializable) (or the inverse). That would make it a type constructor, not a storage class, which we talked about earlier in the thread. I refer you to that discussion. To be clear, I don't want annotations on a type declaration to actually affect the type. Annotations are just that: Annotations. Nothing else. Does a design like that still give rise to the semantic issues you mentioned (it isn't clear what those are)? -- - Alex
Re: D projects list
06.04.2012 1:04, Nick Sabalausky пишет: Denis Shelomovskijverylonglogin@gmail.com wrote in message news:jlkubn$k4f$1...@digitalmars.com... I think it will be great to have a single place for all D related projects so a developer can easily find what is already done (for an example of I didn't now about you project see, e.g. Modern COM Programming in D thread), what is *planned* and what great projects have already failed (and, maybe, reveal it). A draft variant of how I see such page is this with a few projects added (note Planned tag (yes, empty for now)): http://deoma-cmd.ru/d/d-projects-list/ Usage examples: * lets find a D compiler with release or beta maturity: http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release * lets find not abandoned GUI library for D: http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into GitHub so developers can fork and edit it. I'd like to hear (but yes, I can only read, this is NG) any thoughts about this idea. There are already a List of D projects pages on the wiki: See the Projects section in the left nav panel here: http://prowiki.org/wiki4d/wiki.cgi I'm sure new categories could be added as needed. However, I do like the idea have having something that's searchable/sortable as you suggest. I would suggest though, that it be separated into two main parts: 1. Some sort of central database with a documented, publically-accessible machine interface, not a human interface. (And for the love of god, not XML.) 2. A human-usable frontend. That way, alternative frontends can be created. We could even create a D module (maybe in phobos?) to access the list. (IMO, that's how most web apps should work. And then backends that deal with the same type of data should use standardized interfaces. Hell, that's how *real* apps already work (standard file formats, network protocols, etc) - that's how computing finally achieved interoperability decades ago, before web apps sunk us back into the no interoperability dark ages again...But now I'm ranting, I'll stop.) Captcha and/or user management for write-access would be built into #1, not #2. If captcha, then a frontend would tell the backend I want to write access to X resource, or everything (whatever) and the backend would send back a captcha image. The front end would then show it to the user, and relay the answer back to the backend. Actually, better yet, the backend would be user accounts only, but then there'd be a special account for anonymous captcha users. It's be one anon captcha user account for *each* frontend that wanted to allow captcha. The frontend would then use whatever the hell captcha system it wanted and, if the user succeeds, the frontend would transparently communicate with the backend via its own anon captcha user account. And if the captcha system used by the frontend turns out to suck, or be bypassable, or isn't even being used by the frontend, then the backend could disable or revoke that frontend's anon captcha user account. The backend could still, optionally, provide its own official captcha system to any frontends that wanted to use it. Totally agree. You aren't a nut. I'm a nut. Because I believes HTML should die with all present web browsers and JS. And XML because of its frighten overuse. And all slow and buggy web apps. And adobe Flash of course should also die. Damn, they have created slow-by-design thing (e.g. see extremely slow YouTube (and other Flash based video players) video rendering - now you really need a modern PC just to watch a video) and now want to make it faster. With graphical acceleration. It results in BSOD-s (yes, I'm on Windows) using web browsers. Current systems was too stable. Users was too slack. Hello unstable times! Yes, I like ranting more than you... Now on business. I have time now and like you suggestions. So, something like it, I hope, will be done in this year. By the way, I have intentionally added repos to projects list - it is because such catalogue should automatically monitor projects states (the last commit date) when possible. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: D projects list
On Fri, 06 Apr 2012 12:34:09 +0400 Denis Shelomovskij verylonglogin@gmail.com wrote: Because I believes HTML should die with all present web browsers and JS. And XML because of its frighten overuse. And all slow and buggy web apps. And adobe Flash of course should also die. Interesting...but I just wonder what should remain alive? Back to the desktop only? Sincerely, Gour (not liking XML, JS, Flash...) -- Whenever and wherever there is a decline in religious practice, O descendant of Bharata, and a predominant rise of irreligion — at that time I descend Myself. signature.asc Description: PGP signature
Re: Custom attributes (again)
On 4/6/12 3:54 PM, Walter Bright wrote: On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote: What about type declarations? I think those ought to be supported too. E.g. it makes sense to mark an entire type as @attr(serializable) (or the inverse). That would make it a type constructor, not a storage class, which we talked about earlier in the thread. I refer you to that discussion. What's the difference between type constructor and storage class beside the name?
Re: D projects list
06.04.2012 12:49, Gour пишет: On Fri, 06 Apr 2012 12:34:09 +0400 Denis Shelomovskijverylonglogin@gmail.com wrote: Because I believes HTML should die with all present web browsers and JS. And XML because of its frighten overuse. And all slow and buggy web apps. And adobe Flash of course should also die. Interesting...but I just wonder what should remain alive? Back to the desktop only? Why? I didn't say anything about TCP/IP - it can remain for a while :) And desktops now aren't in satisfactory state too. Documents are zipped XML-files, IIRC Microsoft will supply JavaScript as a developing language... -- Денис В. Шеломовский Denis V. Shelomovskij
how to include the module file like C ?
Hi, I can auto index the module file use gcc,
but in D I must append the module file path to dmd args,
if I don't, dmd will give me an error like:
main.o: In function `_Dmain':
main.d:(.text._Dmain+0x15): undefined reference to `_D3lib1ai'
main.d:(.text._Dmain+0x2d): undefined reference to `_D3lib1ai'
collect2: ld returned 1 exit status
--- errorlevel 1
Here is the example:
//main.c
#include stdio.h
#include lib.c
int main(int argc, char** argv){
printf(%d\n, a);
a = 10;
return 0;
}
//lib.c
int a = 1;
[pass] gcc main.c
//main.d
import std.stdio;
import lib;
int main(string[] args){
writeln(lib.a);
lib.a = 10;
return 0;
}
//lib.d
int a = 1;
[pass] dmd main.d lib.d
[failed] dmd main.d
[failed] dmd main.d -inline
[failed] dmd main.d -I./
[failed] dmd main.d -I/full/path/
That mean I can't use geany to do the one key build when import
the modules from file,
anybody known how to include the module file in D ?
Please teach me, thanks very much.
Re: DIP16: Transparently substitute module with package
Le 05/04/2012 23:43, Andrei Alexandrescu a écrit :
On 4/5/12 4:26 PM, Steven Schveighoffer wrote:
On Thu, 05 Apr 2012 17:00:56 -0400, Jonathan M Davis
jmdavisp...@gmx.com wrote:
On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote:
I don't see how. Just move the code into another module and publicly
import that module from std/algorithm.d. Problem pretty much solved.
The issue is code organization. If you want to split up std.algorithm
(or
std.datetime or whatever) into multiple modules, you have to create a
new
package with a completely different name with no connection to the
original
save for the fact that the original publicly imports it.
My view is that people will not import the smaller modules, they will
only ever import std.algorithm.
I think we should be looking for a solution that not only allows
replacing module - package transparently, but also allows people to
import the newly introduced fine-grained modules.
Andrei
Why not limit name collision to name which make sense ?
For instance, import std.a.b.c is a module. if it refers also to a
function, this import doesn't make any sense, so, even if we have a name
collision, this isn't a big deal (except maybe for reflection ?).
Same goes for std.a.b.c(); which is a function call, and obviously not
the module. Here what I propose to resolve names :
1/ import does always find the .d corresponding file. No exception.
2/ Module a.b.c is in package a, a.b and a.b.c . Any package declaration
in a.b.c match package a.b (one level is removed).
3/ When a name is used in the code and have to be resolved, the
following process occurs :
- The compiler find all stuff that have this name.
- The compiler discard all stuffs that have this name and doesn't make
sense.
- If all remaining items are overload of the same item, then standard
best match rule apply.
- If all remaining items aren't in the same module, or overload or
different items, an error occurs. This is never a problem in the case of
big modules splitted in submodules.
Some examples :
a.d
public import a.b; // import a/b.d
class b {
static void foo() {}
}
a/b.d
public import a.b.c; // import a/b/c.d
void foo(int i) {}
a/b/c.d
void foo() {}
main.d
import a;
foo(); // foo from a/b/c.d
foo(2); // foo from a/b.d
a.foo(); // foo from a/b/c.d
a.b.foo(); // Error, match both a/b.d and a/b/c.d
a.b.foo(2); // foo from a/b.d
a.b.c.foo(); // foo from a/b/c.d
Re: DIP16: Transparently substitute module with package
Le 06/04/2012 01:32, Michel Fortin a écrit : On 2012-04-05 21:43:24 +, Andrei Alexandrescu seewebsiteforem...@erdani.org said: I think we should be looking for a solution that not only allows replacing module - package transparently, but also allows people to import the newly introduced fine-grained modules. I think it'd be valuable too. But how do you do that without creating ambiguous fully qualified names? It isn't possible. But as already mentioned, all name doesn't make sense in all situation, so most of the time, disambiguation can be done. Plus, we want to be able to split module when they grow, and in such a situation, collisions will never happen, because all symbols comes from the same module in a first place.
Re: Custom attributes (again)
Am Fri, 06 Apr 2012 00:48:34 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:
It actually can be a problem. In .NET land, there are many
attributes across many projects (and even in the framework itself)
with the same names. It turns out that regular namespace lookup
rules alleviate this problem.
Perhaps a better scheme is:
enum foo = 3;
...
@attr(foo) int x;
That way, foo will follow all the usual rules.
The last time custom attributes where discussed, a C# like model was
proposed. Is there a good reason why we should deviate from the C#
implementation?
C#:
http://msdn.microsoft.com/en-US/library/48zeb25s(v=vs.80).aspx
http://msdn.microsoft.com/en-US/library/sw480ze8(v=vs.100).aspx
http://msdn.microsoft.com/en-US/library/z919e8tw(v=vs.80).aspx
(C# attributes can be applied to almost everything, therefore sometimes
disambiguating targets is necessary. Probably not needed in D):
http://msdn.microsoft.com/en-US/library/b3787ac0(v=vs.80).aspx
Syntax in D would be different of course, but I see absolutely no need
for the redundant (and ugly) @attr.
Declaring a custom attribute:
-
module std.something;
struct Author
{
string name;
public this(string name)
{
this.name = name;
}
}
-
Using it:
-
import std.something; //Usual namespace lookup rules apply to attributes
/*
* @Author(param) calls the constructor of the Author struct and
* attaches the struct instance to test. Probably @Author (without
* parenthesis) coud be made to mean std.something.Author.init
*/
@Author(Johannes Pfau) int test;
-
Attaching attributes multiple times as in C# should be possible.
Using reflection to get that attribute:
-
if(__traits(hasAttribute, test, std.something.Author))
{
Author[] authors = __traits(getAttribute, test,
std.something.Author);
}
-
An array is used here to support attaching the same attribute multiple
times. Of course auto authors = ... should be usable here too.
Re: Custom attributes (again)
On 04/06/2012 09:54 AM, Walter Bright wrote:
On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
What about type declarations? I think those ought to be supported too.
E.g. it
makes sense to mark an entire type as @attr(serializable) (or the
inverse).
That would make it a type constructor, not a storage class, which we
talked about earlier in the thread. I refer you to that discussion.
I think what was discussed there is that
@attr(foo) int x;
Wouldn't change the type of x.
@attr(foo) struct Foo{}
Should add additional information to the type Foo. I don't see any
issues with it, and not supporting it would be very strange.
Re: Custom attributes (again)
On 4/6/12 3:48 PM, Walter Bright wrote:
On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:
It actually can be a problem. In .NET land, there are many attributes
across
many projects (and even in the framework itself) with the same names.
It turns
out that regular namespace lookup rules alleviate this problem.
Perhaps a better scheme is:
enum foo = 3;
...
@attr(foo) int x;
That way, foo will follow all the usual rules.
At least in .Net and Java it's something like this.
1. You declare your attributes. This is something good, because you have
a place to say This attribute is used for marking fields as
non-serializable.
The syntax in Java for declaring an attribute:
public @interface Foo {
String xxx;
int yyy;
}
In D maybe @interface could be used to (in order to avoid introducing
another keyword... or maybe use @attribute instead):
@attribute Foo {
string xxx;
int yyy;
}
2. You use them by using their names. What you are proposing if for
attribute foo to be @attr(foo). But in Java it's @foo.
So in Java you would use that attribute like this:
@Foo(xxx = hello, yyy = 1);
void func() {}
Then you can get the Foo attribute in func, and ask for it's xxx and yyy.
---
Now, your proposal is much simpler and it will become inconvenient in
some cases. For example suppose you want to provide attributes for
serialization (I guess the classic example). With your proposal it would be:
/// This is actually an attribute. Use this together with serialized_name.
enum serialize = 1;
enum serialized_name = 2;
@attr(serialize = true, serialized_name = Foo)
int x;
Now, with the way things are done in Java and C#:
/// Marks a field to be serialized.
@attribute serialize {
/// The name to be used.
/// If not specified, the name of the member will be used instead.
string name;
}
@serialize(name = Foo)
int x;
You can see the syntax is much cleaner. The attribute declaration also
serves as documentation and to group attributes related to the
serialization process.
Now, to implement this is not very much difficult than what you proposed.
1. Introduce the syntax to define attributes. Piece of cake, since it's
much more or less the syntax of a struct, but functions or nested types
are not allowed. Parse them into an AttributeDecl or something like that.
2. When the compiler finds @attr(field = value) it uses normal lookup
rules to find attr. Then it checks it's an attributes. Then all fields
are check in turn to see if their type match. You can probably put there
anything that's compile-time evaluatable, though usually primitive types
and strings are enough. If a field is not specified, it's type.init will
be used.
3. The syntax for querying is almost the same as you proposed:
__traits(hasAttribute, x, serializable) // true
__traits(getAttribtue, x, serializable, name) // Foo
4. Declare the core attributes in object.di or similar: @safe, @nothrow,
etc. You can also document them.
5. Probably deprecate __traits(isSafe) and so on, since hasAttribute can
be used for that.
Re: Custom attributes (again)
On 5 April 2012 20:35, Walter Bright newshou...@digitalmars.com wrote: On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. storage class), or attached to the type (type constructor)? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution. Yes, most certainly the former. The latter is already possible with tricks (a trivial template for instance). An attribute/annotation should associate with select instances/declarations of things. I don't think it should affect the type, although this shows a conceptual problem when referring to existing attributes via the same terminology. Obviously one might consider 'const', 'pure', etc attributes themselves, and they clearly do affect the type. Perhaps that's the key distinction between an '@' attribute(/'annotation'?), and a no-'@' attribute?
Re: Custom attributes (again)
On 5 April 2012 21:32, Timon Gehr timon.g...@gmx.ch wrote: On 04/05/2012 08:05 PM, Andrei Alexandrescu wrote: On 4/5/12 12:44 PM, deadalnix wrote: Le 05/04/2012 19:35, Walter Bright a écrit : On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. At the Lang.NEXT conference over the last 3 days, I was able to talk to many smart people about attributes. But I did find some confusion - are they best attached to the variable/function (i.e. storage class), or attached to the type (type constructor)? I think the former. Attaching it to the type leads to all sorts of semantic issues. From your list of uses, it looks like attaching it to the variable or function is an apropos solution. They should be attached to declarations. The question was whether the declaration affects the type of the declared or not. Andrei Ideally it would be powerful enough to allow changing the type, but most applications probably want the type to stay the same. Didn't someone already say there were existing language defined attributes that could be neatly implemented via libs if the feature were available? Which ones were they?
Re: how to include the module file like C ?
On Fri, 06 Apr 2012 11:36:48 +0200, lzzll ownre...@gmail.com wrote:
Hi, I can auto index the module file use gcc,
but in D I must append the module file path to dmd args,
if I don't, dmd will give me an error like:
main.o: In function `_Dmain':
main.d:(.text._Dmain+0x15): undefined reference to `_D3lib1ai'
main.d:(.text._Dmain+0x2d): undefined reference to `_D3lib1ai'
collect2: ld returned 1 exit status
--- errorlevel 1
Here is the example:
//main.c
#include stdio.h
#include lib.c
int main(int argc, char** argv){
printf(%d\n, a);
a = 10;
return 0;
}
//lib.c
int a = 1;
[pass] gcc main.c
//main.d
import std.stdio;
import lib;
int main(string[] args){
writeln(lib.a);
lib.a = 10;
return 0;
}
//lib.d
int a = 1;
[pass] dmd main.d lib.d
[failed] dmd main.d
[failed] dmd main.d -inline
[failed] dmd main.d -I./
[failed] dmd main.d -I/full/path/
That mean I can't use geany to do the one key build when import the
modules from file,
anybody known how to include the module file in D ?
Please teach me, thanks very much.
You can include a file as text using import(filename), and you can
convert it to code using mixin(string)
mixin(import(lib.d)); will work for you example.
*BUT*... You are completely breaking the module system and working against
the language rather than with it.
I recommend you use the tool rdmd: rdmd main will pick up dependencies
and add them to dmds command line.
Re: Custom attributes (again)
On 04/06/2012 11:57 AM, Manu wrote: I don't think it should affect the type, although this shows a conceptual problem when referring to existing attributes via the same terminology. Obviously one might consider 'const', 'pure', etc attributes themselves, and they clearly do affect the type. Perhaps that's the key distinction between an '@' attribute(/'annotation'?), and a no-'@' attribute? @safe affects the type.
Re: Custom attributes (again)
On 4/6/2012 2:41 AM, Johannes Pfau wrote: The last time custom attributes where discussed, a C# like model was proposed. Is there a good reason why we should deviate from the C# implementation? C# uses a runtime implementation, not a compile time one.
Re: Custom attributes (again)
On 4/6/2012 2:50 AM, Ary Manzana wrote:
The syntax in Java for declaring an attribute:
public @interface Foo {
String xxx;
int yyy;
}
In D maybe @interface could be used to (in order to avoid introducing another
keyword... or maybe use @attribute instead):
@attribute Foo {
string xxx;
int yyy;
}
I don't see the need for creating a new kind of symbol.
2. You use them by using their names. What you are proposing if for attribute
foo to be @attr(foo). But in Java it's @foo.
So in Java you would use that attribute like this:
@Foo(xxx = hello, yyy = 1);
void func() {}
Then you can get the Foo attribute in func, and ask for it's xxx and yyy.
This is a runtime system.
Now, your proposal is much simpler and it will become inconvenient in some
cases. For example suppose you want to provide attributes for serialization (I
guess the classic example). With your proposal it would be:
/// This is actually an attribute. Use this together with serialized_name.
enum serialize = 1;
enum serialized_name = 2;
@attr(serialize = true, serialized_name = Foo)
int x;
No, it would be:
enum serialize = true;
enum serialize_name = Foo;
@attr(serialize, serialized_name) int x;
There would be no initialization in the @attr syntax.
Now, with the way things are done in Java and C#:
/// Marks a field to be serialized.
@attribute serialize {
/// The name to be used.
/// If not specified, the name of the member will be used instead.
string name;
}
@serialize(name = Foo)
int x;
You can see the syntax is much cleaner. The attribute declaration also serves as
documentation and to group attributes related to the serialization process.
I don't see that it is cleaner - there's no particular reason why a new symbol
type needs to be introduced.
Now, to implement this is not very much difficult than what you proposed.
1. Introduce the syntax to define attributes. Piece of cake, since it's much
more or less the syntax of a struct, but functions or nested types are not
allowed. Parse them into an AttributeDecl or something like that.
2. When the compiler finds @attr(field = value) it uses normal lookup rules to
find attr. Then it checks it's an attributes. Then all fields are check in
turn to see if their type match. You can probably put there anything that's
compile-time evaluatable, though usually primitive types and strings are enough.
If a field is not specified, it's type.init will be used.
3. The syntax for querying is almost the same as you proposed:
__traits(hasAttribute, x, serializable) // true
__traits(getAttribtue, x, serializable, name) // Foo
4. Declare the core attributes in object.di or similar: @safe, @nothrow, etc.
You can also document them.
5. Probably deprecate __traits(isSafe) and so on, since hasAttribute can be used
for that.
@safe, @nothrow, etc., require a lot of semantic support in the compiler. They
cannot pretend to be user defined attributes.
Re: Custom attributes (again)
On 6 April 2012 09:47, Walter Bright newshou...@digitalmars.com wrote: On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. I was thinking of something along the lines of what has been proposed here earlier: @attr(identifier = expression) as a storage class, like: @attr(foo = bar + 1) int x; and then: __traits(hasAttribute, x, foo) would return true, and: __traits(getAttribute, x, foo) would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration. The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs. You could also omit the expression, and just have: @attr(bar) int y; I think this is unnecessarily verbose, although certainly workable as a minimum. Although there is one issue that 'foo' can't store compound data. I'd like to see attributes defined as a special sort of struct, and support constructors, this way you can associate rich data, and you can perform complex expressions (ctfe) within the constructor to set defaults, or calculate other details about the attribute if not specified. @replay int x; // this is all that is needed if the attribute associates no variable information // or something associating consideraly more rich information @editor(X coordinate, EditType.Slider, Colour.Red, Verbose description about the thing) // this is still a lot easier to read to me... int x;
Re: Custom attributes (again)
On 4/6/2012 2:18 AM, Ary Manzana wrote: On 4/6/12 3:54 PM, Walter Bright wrote: On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote: What about type declarations? I think those ought to be supported too. E.g. it makes sense to mark an entire type as @attr(serializable) (or the inverse). That would make it a type constructor, not a storage class, which we talked about earlier in the thread. I refer you to that discussion. What's the difference between type constructor and storage class beside the name? static const(int)* foo; static is a storage class. const is a type constructor. There is no type 'static'.
Re: Custom attributes (again)
On 4/6/2012 1:15 AM, Alex Rønne Petersen wrote: On 06-04-2012 09:54, Walter Bright wrote: On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote: What about type declarations? I think those ought to be supported too. E.g. it makes sense to mark an entire type as @attr(serializable) (or the inverse). That would make it a type constructor, not a storage class, which we talked about earlier in the thread. I refer you to that discussion. To be clear, I don't want annotations on a type declaration to actually affect the type. Annotations are just that: Annotations. Nothing else. What would an annotation on a type mean if it does not affect the type? Would it just be baggage carried along? If so, how would that affect types inside of a template, where the type was passed as a type constructor? How would type inference work? Would an alias carry or drop the baggage? How would overloading work? How would covariance work? It's a maze of complex decisions. Does a design like that still give rise to the semantic issues you mentioned (it isn't clear what those are)? Yes. (I know Java does this. But Java has a trivial type system compared with D. It doesn't even have type aliases. It doesn't have type constructors. Etc.)
Re: Custom attributes (again)
On 6 April 2012 10:48, Walter Bright newshou...@digitalmars.com wrote:
On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:
It actually can be a problem. In .NET land, there are many attributes
across
many projects (and even in the framework itself) with the same names. It
turns
out that regular namespace lookup rules alleviate this problem.
Perhaps a better scheme is:
enum foo = 3;
...
@attr(foo) int x;
That way, foo will follow all the usual rules.
What about:
struct editor
{
this(string name, EditType, Colour = Colour.Default, string description =
null)
{
//...
}
blah blah blah
}
@attr(editor(thing,...blah...))
I don't see the advantage over:
@editor(...)
?
Re: Custom attributes (again)
On 6 April 2012 12:41, Johannes Pfau nos...@example.com wrote:
Am Fri, 06 Apr 2012 00:48:34 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:
It actually can be a problem. In .NET land, there are many
attributes across many projects (and even in the framework itself)
with the same names. It turns out that regular namespace lookup
rules alleviate this problem.
Perhaps a better scheme is:
enum foo = 3;
...
@attr(foo) int x;
That way, foo will follow all the usual rules.
The last time custom attributes where discussed, a C# like model was
proposed. Is there a good reason why we should deviate from the C#
implementation?
C#:
http://msdn.microsoft.com/en-US/library/48zeb25s(v=vs.80).aspx
http://msdn.microsoft.com/en-US/library/sw480ze8(v=vs.100).aspx
http://msdn.microsoft.com/en-US/library/z919e8tw(v=vs.80).aspx
(C# attributes can be applied to almost everything, therefore sometimes
disambiguating targets is necessary. Probably not needed in D):
http://msdn.microsoft.com/en-US/library/b3787ac0(v=vs.80).aspx
Syntax in D would be different of course, but I see absolutely no need
for the redundant (and ugly) @attr.
Declaring a custom attribute:
-
module std.something;
struct Author
{
string name;
public this(string name)
{
this.name = name;
}
}
-
Using it:
-
import std.something; //Usual namespace lookup rules apply to attributes
/*
* @Author(param) calls the constructor of the Author struct and
* attaches the struct instance to test. Probably @Author (without
* parenthesis) coud be made to mean std.something.Author.init
*/
@Author(Johannes Pfau) int test;
-
Attaching attributes multiple times as in C# should be possible.
Using reflection to get that attribute:
-
if(__traits(hasAttribute, test, std.something.Author))
{
Author[] authors = __traits(getAttribute, test,
std.something.Author);
}
-
An array is used here to support attaching the same attribute multiple
times. Of course auto authors = ... should be usable here too.
+1
Re: Custom attributes (again)
On 4/6/12 6:12 PM, Walter Bright wrote:
On 4/6/2012 2:50 AM, Ary Manzana wrote:
The syntax in Java for declaring an attribute:
public @interface Foo {
String xxx;
int yyy;
}
In D maybe @interface could be used to (in order to avoid introducing
another
keyword... or maybe use @attribute instead):
@attribute Foo {
string xxx;
int yyy;
}
I don't see the need for creating a new kind of symbol.
2. You use them by using their names. What you are proposing if for
attribute
foo to be @attr(foo). But in Java it's @foo.
So in Java you would use that attribute like this:
@Foo(xxx = hello, yyy = 1);
void func() {}
Then you can get the Foo attribute in func, and ask for it's xxx and
yyy.
This is a runtime system.
Yes, but I'm thinking about a compile-time system (as I showed in the
example usages below).
Now, your proposal is much simpler and it will become inconvenient in
some
cases. For example suppose you want to provide attributes for
serialization (I
guess the classic example). With your proposal it would be:
/// This is actually an attribute. Use this together with
serialized_name.
enum serialize = 1;
enum serialized_name = 2;
@attr(serialize = true, serialized_name = Foo)
int x;
No, it would be:
enum serialize = true;
enum serialize_name = Foo;
@attr(serialize, serialized_name) int x;
There would be no initialization in the @attr syntax.
Hmmm... I didn't get that quite well. You are using the symbol's name as
the attribute name? In my example I missed splitting it into two files:
my_attributes.d:
@attribute serialize { }
my_usage_of_it.d:
import my_attributes;
@serialize(...)
Now, with the way things are done in Java and C#:
/// Marks a field to be serialized.
@attribute serialize {
/// The name to be used.
/// If not specified, the name of the member will be used instead.
string name;
}
@serialize(name = Foo)
int x;
You can see the syntax is much cleaner. The attribute declaration also
serves as
documentation and to group attributes related to the serialization
process.
I don't see that it is cleaner - there's no particular reason why a new
symbol type needs to be introduced.
Now, to implement this is not very much difficult than what you proposed.
1. Introduce the syntax to define attributes. Piece of cake, since
it's much
more or less the syntax of a struct, but functions or nested types are
not
allowed. Parse them into an AttributeDecl or something like that.
2. When the compiler finds @attr(field = value) it uses normal lookup
rules to
find attr. Then it checks it's an attributes. Then all fields are
check in
turn to see if their type match. You can probably put there anything
that's
compile-time evaluatable, though usually primitive types and strings
are enough.
If a field is not specified, it's type.init will be used.
3. The syntax for querying is almost the same as you proposed:
__traits(hasAttribute, x, serializable) // true
__traits(getAttribtue, x, serializable, name) // Foo
4. Declare the core attributes in object.di or similar: @safe,
@nothrow, etc.
You can also document them.
5. Probably deprecate __traits(isSafe) and so on, since hasAttribute
can be used
for that.
@safe, @nothrow, etc., require a lot of semantic support in the
compiler. They cannot pretend to be user defined attributes.
Yes they can. That's how it is done in C# and Java. In fact, IUnknown is
pretending to be an interface and has semantic support in the compiler.
Re: Custom attributes (again)
On 4/6/2012 2:54 AM, Timon Gehr wrote:
Should add additional information to the type Foo. I don't see any issues with
it, and not supporting it would be very strange.
How would:
@attr(foo) int x;
int y;
work? Are x and y the same type or not? Now, consider:
auto c = b ? x : y;
What type does c have? int or @attr(foo)int ? And that's really just the
beginning. How about:
struct S(T) {
T t;
}
Instantiate it with S!int and S!(@attr(foo)int). Are those the same
instantiation, or different? If the same, does S.t have the attribute or not?
And, whatever you choose for the semantics, what is the sensible, intuitive rule
for it?
Re: Custom attributes (again)
On 6 April 2012 13:06, Timon Gehr timon.g...@gmx.ch wrote: On 04/06/2012 11:57 AM, Manu wrote: I don't think it should affect the type, although this shows a conceptual problem when referring to existing attributes via the same terminology. Obviously one might consider 'const', 'pure', etc attributes themselves, and they clearly do affect the type. Perhaps that's the key distinction between an '@' attribute(/'annotation'?), and a no-'@' attribute? @safe affects the type. I realise that, I'm just suggesting this is a possible solution to the confusion... if the distinction were to be made clearly. I guess it's impossible though, can't go claiming 'safe' from the global namespace :)
Re: Custom attributes (again)
On 04/06/2012 12:12 PM, Walter Bright wrote:
On 4/6/2012 2:50 AM, Ary Manzana wrote:
The syntax in Java for declaring an attribute:
public @interface Foo {
String xxx;
int yyy;
}
In D maybe @interface could be used to (in order to avoid introducing
another
keyword... or maybe use @attribute instead):
@attribute Foo {
string xxx;
int yyy;
}
I don't see the need for creating a new kind of symbol.
It would behave like a struct anyway. The issue is whether any struct
should be allowed to be used as an attribute, or whether a runtime
instance of an attribute can be created.
Syntax could just as well be this:
@attribute struct Foo {
// ...
}
2. You use them by using their names. What you are proposing if for
attribute
foo to be @attr(foo). But in Java it's @foo.
So in Java you would use that attribute like this:
@Foo(xxx = hello, yyy = 1);
void func() {}
Then you can get the Foo attribute in func, and ask for it's xxx and
yyy.
This is a runtime system.
In Java, yes. But the general scheme works well even at compile time.
It is possible to evaluate struct constructors at compile time.
enum Foo attr = __traits(getAttribute, func, Foo);
Now, your proposal is much simpler and it will become inconvenient in
some
cases. For example suppose you want to provide attributes for
serialization (I
guess the classic example). With your proposal it would be:
/// This is actually an attribute. Use this together with
serialized_name.
enum serialize = 1;
enum serialized_name = 2;
@attr(serialize = true, serialized_name = Foo)
int x;
No, it would be:
enum serialize = true;
enum serialize_name = Foo;
@attr(serialize, serialized_name) int x;
I don't see how that would work. Do you propose to define attributes
based on the mapping of the name of random manifest constants to their
value? That would be a kludgy hack.
There would be no initialization in the @attr syntax.
Now, with the way things are done in Java and C#:
/// Marks a field to be serialized.
@attribute serialize {
/// The name to be used.
/// If not specified, the name of the member will be used instead.
string name;
}
@serialize(name = Foo)
int x;
You can see the syntax is much cleaner. The attribute declaration also
serves as
documentation and to group attributes related to the serialization
process.
I don't see that it is cleaner
I think it is cleaner on a conceptual level, even if the syntax was
@attr(serialize(Foo))
- there's no particular reason why a new
symbol type needs to be introduced.
There is not strictly a need for a _new_ symbol type, but attribute
lookup should definitely be symbol based and not string/value based. Why
would there be any benefit in bypassing the module system for user
defined attributes?
Re: Custom attributes (again)
On 4/6/2012 3:23 AM, Manu wrote:
What about:
struct editor
{
this(string name, EditType, Colour = Colour.Default, string description =
null)
{
//...
}
blah blah blah
}
@attr(editor(thing,...blah...))
Are you really changing the arguments for every declaration? Or is it one set
that is repeated everywhere?
I don't see the advantage over:
@editor(...)
?
Name collisions with other @ attributes.
Re: Custom attributes (again)
Am Fri, 06 Apr 2012 03:06:51 -0700 schrieb Walter Bright newshou...@digitalmars.com: On 4/6/2012 2:41 AM, Johannes Pfau wrote: The last time custom attributes where discussed, a C# like model was proposed. Is there a good reason why we should deviate from the C# implementation? C# uses a runtime implementation, not a compile time one. OK, but my post was only about the syntax, there's no runtime/compile time specific part in it (the struct's constructor has to be called using CTFE instead of at runtime, but that's the only difference I see)
Re: Custom attributes (again)
On 4/6/12 6:29 PM, Timon Gehr wrote:
On 04/06/2012 12:12 PM, Walter Bright wrote:
On 4/6/2012 2:50 AM, Ary Manzana wrote:
The syntax in Java for declaring an attribute:
public @interface Foo {
String xxx;
int yyy;
}
In D maybe @interface could be used to (in order to avoid introducing
another
keyword... or maybe use @attribute instead):
@attribute Foo {
string xxx;
int yyy;
}
I don't see the need for creating a new kind of symbol.
It would behave like a struct anyway. The issue is whether any struct
should be allowed to be used as an attribute, or whether a runtime
instance of an attribute can be created.
Syntax could just as well be this:
@attribute struct Foo {
// ...
}
True, I struct can be fine. And I don't see any problem in using it in
runtime. Though I'm sure nobody would like it to remain in the obj file
if it's only used at compile time...
Re: Custom attributes (again)
On 04/06/2012 11:41 AM, Johannes Pfau wrote:
Syntax in D would be different of course, but I see absolutely no need
for the redundant (and ugly) @attr.
Declaring a custom attribute:
-
module std.something;
struct Author
{
string name;
public this(string name)
{
this.name = name;
}
}
-
Using it:
-
import std.something; //Usual namespace lookup rules apply to attributes
/*
* @Author(param) calls the constructor of the Author struct and
* attaches the struct instance to test. Probably @Author (without
* parenthesis) coud be made to mean std.something.Author.init
*/
@Author(Johannes Pfau) int test;
-
Attaching attributes multiple times as in C# should be possible.
Using reflection to get that attribute:
-
if(__traits(hasAttribute, test, std.something.Author))
{
Author[] authors = __traits(getAttribute, test,
std.something.Author);
}
-
An array is used here to support attaching the same attribute multiple
times. Of course auto authors = ... should be usable here too.
This all seems very reasonable. I think this is how things should work.
(maybe syntax will need to be different, because Walter does not seem to
like the idea of un-reserving @identifier.)
Re: Custom attributes (again)
On 04/06/2012 12:28 PM, Walter Bright wrote:
On 4/6/2012 3:23 AM, Manu wrote:
What about:
struct editor
{
this(string name, EditType, Colour = Colour.Default, string
description = null)
{
//...
}
blah blah blah
}
@attr(editor(thing,...blah...))
Are you really changing the arguments for every declaration? Or is it
one set that is repeated everywhere?
Yes, allowing the arguments to be different is a crucial feature.
Custom attributes are not a boolean thing, that is just the case for
built-in ones. They are arbitrary data that is attached to a declaration
and can then be used to build powerful semantics using compile time
reflection.
I don't see the advantage over:
@editor(...)
?
Name collisions with other @ attributes.
Which other attributes? Built-in ones? Otherwise, the D module system
will be great at disambiguating the collisions as soon as inaccessible
private symbols do not participate in symbol name collisions any more.
Maybe we could just keep all the lower case @attributes reserved in
order to be future proof.
Re: Custom attributes (again)
Am Fri, 06 Apr 2012 12:43:27 +0200 schrieb Timon Gehr timon.g...@gmx.ch: On 04/06/2012 12:28 PM, Walter Bright wrote: On 4/6/2012 3:23 AM, Manu wrote: I don't see the advantage over: @editor(...) ? Name collisions with other @ attributes. Which other attributes? Built-in ones? Otherwise, the D module system will be great at disambiguating the collisions as soon as inaccessible private symbols do not participate in symbol name collisions any more. Maybe we could just keep all the lower case @attributes reserved in order to be future proof. Or add a reserved pseudo-namespace (like e.g 'builtin') for compiler defined attributes and use normal namespace resolution for those: @safe = @builtin.safe
Re: Custom attributes (again)
On 6 April 2012 13:12, Walter Bright newshou...@digitalmars.com wrote:
On 4/6/2012 2:50 AM, Ary Manzana wrote:
The syntax in Java for declaring an attribute:
public @interface Foo {
String xxx;
int yyy;
}
In D maybe @interface could be used to (in order to avoid introducing
another
keyword... or maybe use @attribute instead):
@attribute Foo {
string xxx;
int yyy;
}
I don't see the need for creating a new kind of symbol.
I don't think it's necessary to declare the struct as @attribute
explicitly, the '@' can easily imply the usage all on its own in the
declaration. The struct would remain a perfectly normal struct, and will be
useful if you want to get a struct somewhere in the code to inspect details
about the attribute.
@SomeStruct(blah) int x;
..
SomeStruct s = __traits(getAttribute, SomeStruct, x);
... do some stuff with the information that x was attributed
static if(s.thing == ??)
2. You use them by using their names. What you are proposing if for
attribute
foo to be @attr(foo). But in Java it's @foo.
So in Java you would use that attribute like this:
@Foo(xxx = hello, yyy = 1);
void func() {}
Then you can get the Foo attribute in func, and ask for it's xxx and
yyy.
This is a runtime system.
It doesn't need to be runtime. The syntax works perfectly at compile time?
Now, your proposal is much simpler and it will become inconvenient in some
cases. For example suppose you want to provide attributes for
serialization (I
guess the classic example). With your proposal it would be:
/// This is actually an attribute. Use this together with serialized_name.
enum serialize = 1;
enum serialized_name = 2;
@attr(serialize = true, serialized_name = Foo)
int x;
No, it would be:
enum serialize = true;
enum serialize_name = Foo;
@attr(serialize, serialized_name) int x;
There would be no initialization in the @attr syntax.
Please don't. We've gone from a minor case of bracket spam now to a whole
bunch of extra lines for every single member, and you've also removed the
tight syntactical connection of the values from their attribute declaration
(one of the most important details, its safety, when people update/edit
classes). This is fast approaching the disconnected enum table which is the
whole thing we're trying to avoid.
There's also a namespace/scope problem here. 2 different systems from 2
different libraries will almost certainly use the 'serialise' attribute.
Now, with the way things are done in Java and C#:
/// Marks a field to be serialized.
@attribute serialize {
/// The name to be used.
/// If not specified, the name of the member will be used instead.
string name;
}
@serialize(name = Foo)
int x;
You can see the syntax is much cleaner. The attribute declaration also
serves as
documentation and to group attributes related to the serialization
process.
I don't see that it is cleaner - there's no particular reason why a new
symbol type needs to be introduced.
See my point above, I don't think there's any need for a new symbol type...
The compiler would just keep a little table of attributes alongside
declarations, which you can query if you want to.
Re: Custom attributes (again)
On 04/06/2012 12:23 PM, Walter Bright wrote:
On 4/6/2012 2:54 AM, Timon Gehr wrote:
Should add additional information to the type Foo. I don't see any
issues with
it, and not supporting it would be very strange.
How would:
@attr(foo) int x;
int y;
work? Are x and y the same type or not?
Yes, they are.
(But a future extension might leave this choice up to 'foo')
Now, consider:
auto c = b ? x : y;
What type does c have? int or @attr(foo)int ? And that's really just the
beginning. How about:
struct S(T) {
T t;
}
Instantiate it with S!int and S!(@attr(foo)int). Are those the same
instantiation, or different? If the same, does S.t have the attribute or
not?
There is no such thing as an @attr(foo) int, because @attr is not a type
constructor.
And, whatever you choose for the semantics, what is the sensible,
intuitive rule for it?
Custom attributes apply to the symbol declaration. Because any symbol is
declared just once, there is never any ambiguity. There is no conceptual
gap between
@attr(foo) int x;
and
@attr(bar) struct S{...}
Obviously @attr(bar) changes S, but there is only one declaration of S.
Re: Custom attributes (again)
On 4/6/2012 3:27 AM, Ary Manzana wrote: @safe, @nothrow, etc., require a lot of semantic support in the compiler. They cannot pretend to be user defined attributes. Yes they can. That's how it is done in C# and Java. In fact, IUnknown is pretending to be an interface and has semantic support in the compiler. All the semantics of @safe are in the compiler. None of it can be user defined. There's just no point to trying to make it user defined. It's like trying to make int user defined. IUnknown's semantics are nearly all user-defined.
Re: Custom attributes (again)
Walter Bright wrote:
Are you really changing the arguments for every declaration? Or is it
one set that is repeated everywhere?
The former.
I don't see the advantage over:
@editor(...)
?
Name collisions with other @ attributes.
The same applies to other identifiers, like class named class. NET has
predefined attributes too, but they use the same syntax as the custom ones:
[MyAttr(5)] int x;
I think @MyAttr(5) declaration looks more readable than
@attr(MyAttr(5)). To avoid name clashes, in case of using builtin name,
qualified identifier should be used:
@myModule.pure
@pure
void fn() {}
Re: Custom attributes (again)
On 04/06/2012 12:16 PM, Walter Bright wrote: On 4/6/2012 1:15 AM, Alex Rønne Petersen wrote: On 06-04-2012 09:54, Walter Bright wrote: On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote: What about type declarations? I think those ought to be supported too. E.g. it makes sense to mark an entire type as @attr(serializable) (or the inverse). That would make it a type constructor, not a storage class, which we talked about earlier in the thread. I refer you to that discussion. To be clear, I don't want annotations on a type declaration to actually affect the type. Annotations are just that: Annotations. Nothing else. What would an annotation on a type mean if it does not affect the type? I don't get that either, it has to affect the type. It does not have any effects on the semantics of instances on the type though. Name mangling can stay the same though. Would it just be baggage carried along? Yes. If so, how would that affect types inside of a template, where the type was passed as a type constructor? How do you pass a type as a type constructor? How would type inference work? Just as it does now. Would an alias carry or drop the baggage? Carry. An alias does not change the referenced symbol. How would overloading work? How would covariance work? As they do now. Custom attributes don't have semantic meaning recognised by the compiler. They are just data. It's a maze of complex decisions. I think you can add a list of annotations to the class in the AST that represents a declaration (the common superclass of all declarations) and everything will just work. Does a design like that still give rise to the semantic issues you mentioned (it isn't clear what those are)? Yes. (I know Java does this. But Java has a trivial type system compared with D. It doesn't even have type aliases. It doesn't have type constructors. Etc.) I think there is some sort of communication problem, because the feature that is being requested is quite simple. It would probably be valuable if you could point out the issues you see in detail (using example code.)
Re: Custom attributes (again)
Piotr Szturmaj wrote:
@myModule.pure
@pure
void fn() {}
should be:
@myModule.safe
@safe
void fn() {}
Re: Custom attributes (again)
On 6 April 2012 13:28, Walter Bright newshou...@digitalmars.com wrote:
On 4/6/2012 3:23 AM, Manu wrote:
What about:
struct editor
{
this(string name, EditType, Colour = Colour.Default, string description
= null)
{
//...
}
blah blah blah
}
@attr(editor(thing,...blah..**.))
Are you really changing the arguments for every declaration? Or is it one
set that is repeated everywhere?
Of course, what's the point otherwise? This is the very definition of
annotation.
Everything needs to be exposed in the editor differently.
The power of attributes are that they are tightly syntactically bound to
the items they attribute. Nobody can change any class/struct without having
the syntax force them to make any necessary corrections to their attributes
too.
I don't see the advantage over:
@editor(...)
?
Name collisions with other @ attributes.
If they were declared as normal structs, they would follow normal namespace
rules.
@company.lib.MyAttribute(...) should also be a valid expression.
The only collisions are @trusted, @safe... I think programmers can handle a
few reserved keywords.
I already can't go and name a variable whatever I want for the same
reason: int private = 10;
Re: Mascot for D
On 06/04/2012 05:42, F i L wrote: crudbug wrote: May be a Dodo as a mascot ? I doubt a Dodo would send a positive message... considering they when extinct years ago and where considered to have very little intelligence. I think a Martian is the best idea. My first thought when I saw this thread was some kind of cute little Astronaut. I like the name Digital Martian but worry that any kind of alien mascot would lack originality or require explanation. What does it take to be a Martian? DO the Mars Rovers count? A...
Re: Custom attributes (again)
On 04/06/2012 12:17 PM, Walter Bright wrote:
On 4/6/2012 2:18 AM, Ary Manzana wrote:
On 4/6/12 3:54 PM, Walter Bright wrote:
On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
What about type declarations? I think those ought to be supported too.
E.g. it
makes sense to mark an entire type as @attr(serializable) (or the
inverse).
That would make it a type constructor, not a storage class, which we
talked about earlier in the thread. I refer you to that discussion.
What's the difference between type constructor and storage class
beside the
name?
static const(int)* foo;
static is a storage class. const is a type constructor. There is no type
'static'.
Still, the 'static' in
static struct S{
// ...
}
Affects S. Correct?
Re: how to include the module file like C ?
On Friday, 6 April 2012 at 09:56:19 UTC, simendsjo wrote: I recommend you use the tool rdmd: rdmd main will pick up dependencies and add them to dmds command line. Rdmd works perfect, I just need replace linker=dmd -w -of%e %f to linker=rdmd --build-only -w -of%e %f in filetypes.d for geany then all things will be good. Thank you very much !
Re: Custom attributes (again)
On 04/06/2012 12:53 PM, Walter Bright wrote: On 4/6/2012 3:27 AM, Ary Manzana wrote: @safe, @nothrow, etc., require a lot of semantic support in the compiler. They cannot pretend to be user defined attributes. Yes they can. That's how it is done in C# and Java. In fact, IUnknown is pretending to be an interface and has semantic support in the compiler. All the semantics of @safe are in the compiler. None of it can be user defined. There's just no point to trying to make it user defined. It's like trying to make int user defined. IUnknown's semantics are nearly all user-defined. The proposal is not to make the semantics of @safe user defined. I think he proposes to make 'safe' a symbol that is looked up like an user defined symbol. Some languages do the same for the built-in integer type.
Re: Mascot for D
On 6.4.2012 13:05, Alix Pexton wrote: My first thought when I saw this thread was some kind of cute little Astronaut. I like the name Digital Martian but worry that any kind of alien mascot would lack originality or require explanation. What does it take to be a Martian? DO the Mars Rovers count? A... If you are to venture into robot realm, we could use the bottom half of R2D2 - it is as close to D2 as anything can get and it is almost universally recognized... Just musing :-)
Re: Custom attributes (again)
On 04/06/12 11:18, Ary Manzana wrote:
On 4/6/12 3:54 PM, Walter Bright wrote:
On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
What about type declarations? I think those ought to be supported too.
E.g. it
makes sense to mark an entire type as @attr(serializable) (or the
inverse).
That would make it a type constructor, not a storage class, which we
talked about earlier in the thread. I refer you to that discussion.
What's the difference between type constructor and storage class beside
the name?
@attr(deprecated) struct T { int blah; } // every instance of S now marked with
it.
struct S { int blah; }
@attr(deprecated) S si; // just si marked; think static S si; etc
I actually don't like the proposed scheme - it's both way to verbose and not
nearly sufficient.
I have to leave soon and don't have the time to fully describe the problems, but
just a few key points:
- Both of the above should work; the storage class is the more important part.
Wouldn't just having the type-attributes automatically propagate (as a default
storage class) to the instances, w/o affecting the type in any way, be
enough?
- If the above would work, then there has to be a way to remove an attribute
from
some instances.
- Attributes needs to be declared in some way, otherwise a typo will go
undetected
and you may not notice it until it's too late. Think @attr(serialisable) etc
- Attributes need to be mergeable, ie you really don't want to mark a
significant
number of symbols as serializable, exported-to-X, exported-to-Y etc. Something
like
alias @attr(serializable, export_X, export_Y) new_attr;
@attr(new_attr) int i;
might work.
- At the very least __traits(getAttribute, x, foo) needs to be something like
__traits(@attr, x, foo); even better would be x.@attr(foo);.
- Should attributes be strings? That would avoid clashes with keywords. OTOH
that would mean that attribute definitions needs to use different syntax than
plain structs. Hmm, maybe that would be a good thing anyway.
- Namespaces. There needs to be a system NS and a compiler-specific NS. So that
you can do things like @attr(__GNU, flatten, hot) instead of
pragma(GNU_attribute, flatten, hot).
- Null/empty attributes, ie alias @attr() new_attr;, should work; necessary eg
when the compiler lacks support for certain features.
There are probably many more issues, these are just the few obvious ones that
immediately come to mind.
artur
Re: Custom attributes (again)
On 6 April 2012 13:23, Walter Bright newshou...@digitalmars.com wrote: On 4/6/2012 2:54 AM, Timon Gehr wrote: Should add additional information to the type Foo. I don't see any issues with it, and not supporting it would be very strange. How would: @attr(foo) int x; int y; work? Are x and y the same type or not? Yes they are the same type. Now, consider: auto c = b ? x : y; c was not attributed, and has no attributes. @blah auto c = b ? x : y; // NOW 'c' is attributed with 'blah', as useless as that is :) Attributes are on the declaration, and not passed around.
Re: Custom attributes (again)
On 4/6/12 7:09 PM, Timon Gehr wrote: On 04/06/2012 12:53 PM, Walter Bright wrote: On 4/6/2012 3:27 AM, Ary Manzana wrote: @safe, @nothrow, etc., require a lot of semantic support in the compiler. They cannot pretend to be user defined attributes. Yes they can. That's how it is done in C# and Java. In fact, IUnknown is pretending to be an interface and has semantic support in the compiler. All the semantics of @safe are in the compiler. None of it can be user defined. There's just no point to trying to make it user defined. It's like trying to make int user defined. IUnknown's semantics are nearly all user-defined. The proposal is not to make the semantics of @safe user defined. I think he proposes to make 'safe' a symbol that is looked up like an user defined symbol. Some languages do the same for the built-in integer type. The compiler does the same for TypeInfo, TypeInfo_ClassDeclaration or what ever, Object, etc. I'm just proposing @safe to be seen as a user-defined attribute, but implemented in the compiler with special semantic. I'm saying it so that lookup rules become easier: just search. No special cases like if the attribute name is safe. Of course, treat the special cases later inside the compiler code.
Re: Custom attributes (again)
On 6 April 2012 14:03, Timon Gehr timon.g...@gmx.ch wrote: It's a maze of complex decisions. I think you can add a list of annotations to the class in the AST that represents a declaration (the common superclass of all declarations) and everything will just work. Yeah, I always imagined it being about that simple too... are you able to proof the concept? (I know Java does this. But Java has a trivial type system compared with D. It doesn't even have type aliases. It doesn't have type constructors. Etc.) I think there is some sort of communication problem, because the feature that is being requested is quite simple. It would probably be valuable if you could point out the issues you see in detail (using example code.) Indeed.
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 23:18:07 -0400, Ary Manzana a...@esperanto.org.ar
wrote:
On 4/5/12 10:55 PM, Steven Schveighoffer wrote:
On Fri, 30 Mar 2012 10:46:19 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
Starting a new thread from one in announce:
http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP16
Please comment, after which Walter will approve. Walter's approval
means that he would approve a pull request implementing DIP16 (subject
to regular correctness checks).
Destroy!
BTW, this case makes the part of DIP16 which wants to shortcut fully
qualified names invalid, or at least costly (I posted this code in
another part of the thread, but I thought I'd bring it up higher).
The following is valid code today:
a/b.d:
module a.b;
void foo() {}
struct b
{
static void foo() {}
}
main.d:
import a.b;
void main()
{
a.b.foo();
}
If DIP16 were to be implemented, this becomes ambiguous. Is a.b.foo()
the module function foo() from a.b, or is it a shortcut for a.b.b.foo()?
It's a shortcut to the module function foo().
If I replace main.d with:
void main() {
foo();
}
Is foo() the module function foo() from a.b, or is it a shortcut for
a.b.b.foo()? Here you have no doubts. What your mind does it: find a top
level symbol foo in all imported modules. If you find more than one,
error.
That's slightly different, because you must *always* qualify struct b's
foo with a preceeding b.
You must apply the same logic for a.b.foo(). First you search foo in
the a.b symbol. Here you find it: it's the top level function foo in
a.b. Then you stop searching.
However, if you can't find it in the module a.b, you search a top
level symbol foo in all modules that are in package a.b. That's it.
You don't search foo in every possible nesting: just module nesting.
What if a.b is a struct, and it's the only possible match? We don't
search for it? At some point the struct b has to come into play. Or are
you saying we cannot shortcut struct FQN's?
I suppose if we prefer to match modules before types, then name lookup for
fully qualified names only becomes ambiguous with packages allowed to have
their own modules, so it shouldn't affect existing code.
The main issue is, because you can shortcut the FQN, and a chain of
identifiers can have repeated identifiers in them, ambiguity is
possible.
As I said before, it's not a shortcut of the FQN: it's just a shortcut
for the module name.
My example *was* a shortcut for the module name. I did not imply that you
could shortcut the other parts of the FQN.
What about hijacking though? For example:
module a.b
struct c
{
static void foo() {}
}
people now use a.c.foo() to avoid having to type the whole thing
But along comes someone who creates:
module a.c;
void foo() {}
Now, doesn't this usurp a.c.foo() without warning?
-Steve
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 19:14:42 -0400, Jonathan M Davis jmdavisp...@gmx.com wrote: On Thursday, April 05, 2012 17:33:50 Steven Schveighoffer wrote: Why do we ever need to split modules for documentation? Just fix the doc generator so it's not as monolithic. For instance, have one page per class or struct. That may or may not be desirable (certainly in the case of smaller types, I'd argue that it isn't). By doing it on a module basis, you have far more control. But regardless, that would be a major change to ddoc. ddoc's output leaves a lot to be desired. The unorganized links at the top suck. Using module order to show symbols instead of category of symbols. How is a doc page ever too big? Even std.datetime loads in a second. It's more that it's too disorganized. And if all you care about is sub-modules for implementation and want all of the functions in the same module still, then this DIP is pointless. All you have to do is declare undocumented sub-modules which hold the various implementations and have the actual module call them. We already do this sort of thing in Phobos to get around static destructors screaming about circular dependencies. You are starting to see my point :) But I think the issue is not so much that you are splitting the implementation, but splitting up the API into related modules. As I understand it, the entire point of this DIP is to enable splitting up the API cleanly without breaking code. The implementation can already be split up seemlessly. As can the API via public imports. -Steve
Re: DIP16: Transparently substitute module with package
On Thu, 05 Apr 2012 17:43:24 -0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 4/5/12 4:26 PM, Steven Schveighoffer wrote: On Thu, 05 Apr 2012 17:00:56 -0400, Jonathan M Davis jmdavisp...@gmx.com wrote: On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote: I don't see how. Just move the code into another module and publicly import that module from std/algorithm.d. Problem pretty much solved. The issue is code organization. If you want to split up std.algorithm (or std.datetime or whatever) into multiple modules, you have to create a new package with a completely different name with no connection to the original save for the fact that the original publicly imports it. My view is that people will not import the smaller modules, they will only ever import std.algorithm. I think we should be looking for a solution that not only allows replacing module - package transparently, but also allows people to import the newly introduced fine-grained modules. Of course you *can* do this. I think you mean and allows one to refer to the fine grained module as if it were imported from the top-level module. I don't think that benefit is very great. Why shouldn't we expect people to use the module name they actually imported to refer to a module? If you want selective import, we have: import std.algorithm : sort; I think the real benefit to splitting up the module comes from being able to draw clear lines between which pieces of a large module are related. I feel like most people will still import the main package module, and not the submodules. I don't think I ever wrote a piece of java code that didn't have: import java.io.*; I keep coming back to std.container. Already it's large, and full of unrelated types. It's only going to get worse. Now, I fully agree that having some way to import a package by itself without having to import all its modules would be ideal (as well as splitting a large module into submodules that live in the same namespace). I think DIP15 has that covered. -Steve
Re: Custom attributes (again)
Le 06/04/2012 11:41, Johannes Pfau a écrit :
Am Fri, 06 Apr 2012 00:48:34 -0700
schrieb Walter Brightnewshou...@digitalmars.com:
On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:
It actually can be a problem. In .NET land, there are many
attributes across many projects (and even in the framework itself)
with the same names. It turns out that regular namespace lookup
rules alleviate this problem.
Perhaps a better scheme is:
enum foo = 3;
...
@attr(foo) int x;
That way, foo will follow all the usual rules.
The last time custom attributes where discussed, a C# like model was
proposed. Is there a good reason why we should deviate from the C#
implementation?
C#:
http://msdn.microsoft.com/en-US/library/48zeb25s(v=vs.80).aspx
http://msdn.microsoft.com/en-US/library/sw480ze8(v=vs.100).aspx
http://msdn.microsoft.com/en-US/library/z919e8tw(v=vs.80).aspx
(C# attributes can be applied to almost everything, therefore sometimes
disambiguating targets is necessary. Probably not needed in D):
http://msdn.microsoft.com/en-US/library/b3787ac0(v=vs.80).aspx
Syntax in D would be different of course, but I see absolutely no need
for the redundant (and ugly) @attr.
Declaring a custom attribute:
-
module std.something;
struct Author
{
string name;
public this(string name)
{
this.name = name;
}
}
-
Using it:
-
import std.something; //Usual namespace lookup rules apply to attributes
/*
* @Author(param) calls the constructor of the Author struct and
* attaches the struct instance to test. Probably @Author (without
* parenthesis) coud be made to mean std.something.Author.init
*/
@Author(Johannes Pfau) int test;
-
Attaching attributes multiple times as in C# should be possible.
Using reflection to get that attribute:
-
if(__traits(hasAttribute, test, std.something.Author))
{
Author[] authors = __traits(getAttribute, test,
std.something.Author);
}
-
An array is used here to support attaching the same attribute multiple
times. Of course auto authors = ... should be usable here too.
That is a really nice proposal !
Re: DIP16: Transparently substitute module with package
On 2012-04-06 09:41:27 +, deadalnix deadal...@gmail.com said: Why not limit name collision to name which make sense ? You're proposing that fully qualified names sometime work and sometime do not work based on what you've imported and the context of usage. This makes any FQN conflict hard to detect, because the error will be dependent on the context in which you use the name. You say it'll never happen for modules spitted in submodules, but I disagree. Someday, someone will add a symbol to a submodule without checking every package/module file underneath. Unit tests in the module won't catch the problem because for them to catch the problem the parent module/package has to be imported. Only on certain usages, with the right imports and in the right context will the error occur. In fact, if you add disambiguation based on what makes sense you're making the error more obscure and harder to detect in the first place because sometime it'll occur and sometime not depending on hard to predict conditions. If we allow arbitrary symbols to live inside a package, any conflict in FQN should be caught as soon as possible, ideally as soon as you compile after having added the symbol, and even if you don't use the symbol anywhere. Just like how you get an error today when you try to import a module matching a known package name, you shouldn't be allowed to import a module matching a known symbol name, or create a symbol matching a module fully qualified name. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Custom attributes (again)
On 2012-04-06 05:30, Ary Manzana wrote:
I don't understand the difference between storage class and type
constructor. I guess I do. But my answer is the same as deadalnix: they
are attached to declarations (at compile time).
Can you give us an example of the confusion that arose? I can't
understand it without examples.
I think it should work like this:
@custom
class Foo {
@ custom
void bar() { }
void baz() { }
}
class Other {}
__traits(hasAttribute, Foo, 'custom') -- true
__traits(hasAttribute, Other, 'custom') -- false
// I have no idea how to iterate the members of Foo, or get a reference
to the bar method... I can't understand what __traits(getMember)
returns from the docs...
I would like to have the possibility to attach attributes to types and
parameters as well. Some think like this:
class Bar
{
@not_null(Foo) bar (@custom int a) {}
}
Where @not_null is attached to Foo and @custom is attached to a.
--
/Jacob Carlborg
Re: Custom attributes (again)
On 2012-04-06 09:17, Kapps wrote: Secondly, from what I can tell it's an arbitrary key value combo. What would happen if you're working on a larger project and two unrelated libraries try to use the same attribute name to mean different things? With the module system this issue doesn't exist since you have to import it and can selectively/privately do so, but from what I understand the method you're proposing doesn't declare the attribute itself at all. Am I just misunderstanding this part? The way I'm thinking of attributes is that they are declared, somehow, in a module. Since it's declared in a module it would have the same rules any other declared symbol, with the possibility to use a fully qualified name. -- /Jacob Carlborg
Re: Custom attributes (again)
On 2012-04-06 08:47, Walter Bright wrote: On 4/5/2012 5:00 AM, Manu wrote: C# and Java both have attributes, following these established design patterns, I don't think there should be any mystery over how they should be implemented. I was thinking of something along the lines of what has been proposed here earlier: @attr(identifier = expression) as a storage class, like: @attr(foo = bar + 1) int x; and then: __traits(hasAttribute, x, foo) would return true, and: __traits(getAttribute, x, foo) would return the expression (bar+1). The expression would be compile-time only, evaluated at the point of declaration. The implementation is simple enough, just attach to each symbol an array of (identifier,expression) pairs. You could also omit the expression, and just have: @attr(bar) int y; I'm not a particular fan of that syntax. I would go with: @identifier(key = value/expression) Like: @foo(k1 = bar + 1, k2 = bar + 2) int x; If the attribute takes one key-value pair: @foo(value = bar + 1) int x; Can be shortened like: @foo(bar + 1) int x; And for attributes that don't take any values: @foo int x; -- /Jacob Carlborg
Re: Custom attributes (again)
On 2012-04-06 09:32, Walter Bright wrote: Could do: [[name = value]] I suppose. Not sure what's better. No. See my other reply. -- /Jacob Carlborg
Re: Custom attributes (again)
On 04/06/2012 02:23 PM, Jacob Carlborg wrote:
I would like to have the possibility to attach attributes to types and
parameters as well. Some think like this:
class Bar
{
@not_null(Foo) bar (@custom int a) {}
}
Where @not_null is attached to Foo and @custom is attached to a.
@not_null cannot be attached to Foo. It would have to create a new
symbol @not_null(Foo). And then, all the concerns Walter has raised apply.
Re: Custom attributes (again)
On 2012-04-06 09:48, Walter Bright wrote: On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote: It actually can be a problem. In .NET land, there are many attributes across many projects (and even in the framework itself) with the same names. It turns out that regular namespace lookup rules alleviate this problem. Perhaps a better scheme is: enum foo = 3; ... @attr(foo) int x; That way, foo will follow all the usual rules. What would 3 do in this case? Be the value of the attribute? -- /Jacob Carlborg
Re: D projects list
On Fri, 06 Apr 2012 13:24:35 +0400 Denis Shelomovskij verylonglogin@gmail.com wrote: Why? I didn't say anything about TCP/IP - it can remain for a while :) Ahh, OK. ;) And desktops now aren't in satisfactory state too. Documents are zipped XML-files, Really? I use AsciiDoc/LaTeX/LyX for documents and those which are in XML (Gnucash, GNumeric,..) are unzipped: :-) Sincerely, Gour -- But a person free from all attachment and aversion and able to control his senses through regulative principles of freedom can obtain the complete mercy of the Lord. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: Custom attributes (again)
On 2012-04-06 09:47, Walter Bright wrote: On 4/6/2012 12:42 AM, Alex Rønne Petersen wrote: Also, by storage class do you mean it will work only on fields? No. Storage classes work on fields, functions, and variables. They need to be attachable to classes, structs, enums and so on as well. -- /Jacob Carlborg
Re: Custom attributes (again)
Jacob Carlborg wrote:
I would like to have the possibility to attach attributes to types and
parameters as well. Some think like this:
class Bar
{
@not_null(Foo) bar (@custom int a) {}
}
Where @not_null is attached to Foo and @custom is attached to a.
Do you mean return type? I think your syntax has some serious
disadvantages. Consider parameters and multiple attributes.
For return types I'd like to see something like this:
@return: not_null
@return: MyAttr(foo)
Foo bar(@custom int a) {}
This is similar to C#'s [return: MyAttr]. Alternatively it might be:
@return(not_null)
@return(MyAttr(foo))
Re: Custom attributes (again)
On 2012-04-06 11:50, Ary Manzana wrote: On 4/6/12 3:48 PM, Walter Bright wrote: On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote: It actually can be a problem. In .NET land, there are many attributes across many projects (and even in the framework itself) with the same names. It turns out that regular namespace lookup rules alleviate this problem. Perhaps a better scheme is: enum foo = 3; ... @attr(foo) int x; That way, foo will follow all the usual rules. At least in .Net and Java it's something like this. 1. You declare your attributes. This is something good, because you have a place to say This attribute is used for marking fields as non-serializable. This is much better, as I've said before. -- /Jacob Carlborg
Re: Custom attributes (again)
On 2012-04-06 12:12, Walter Bright wrote: I don't see the need for creating a new kind of symbol. If you create a new symbol, i.e. Foo then it would obey the normal look up rules. This is a runtime system. Says who? It doesn't need to be in D. I don't see that it is cleaner - there's no particular reason why a new symbol type needs to be introduced. For attributes with a single value this syntax sugar can be allowed (and is in Java): @serialize(Foo) int x; I think that is clean. -- /Jacob Carlborg
Re: Custom attributes (again)
On 2012-04-06 12:28, Walter Bright wrote: Name collisions with other @ attributes. Just as we have today with keywords and symbols, I don't see the problem. -- /Jacob Carlborg
Re: D projects list
Denis Shelomovskij wrote: I think it will be great to have a single place for all D related projects so a developer can easily find what is already done (for an example of I didn't now about you project see, e.g. Modern COM Programming in D thread), what is *planned* and what great projects have already failed (and, maybe, reveal it). A draft variant of how I see such page is this with a few projects added (note Planned tag (yes, empty for now)): http://deoma-cmd.ru/d/d-projects-list/ Usage examples: * lets find a D compiler with release or beta maturity: http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release * lets find not abandoned GUI library for D: http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into GitHub so developers can fork and edit it. I'd like to hear (but yes, I can only read, this is NG) any thoughts about this idea. It's a great idea. I used djangopackages.com a lot when I was doing a django project, something like this would be awesome for D. You might like to check it out, it has some nice features. So, apparently djangopackages.com is built with opencomparison, which is an open source project in itself: http://opencomparison.org/
Re: Custom attributes (again)
On 6 April 2012 15:38, Piotr Szturmaj bncr...@jadamspam.pl wrote:
Jacob Carlborg wrote:
I would like to have the possibility to attach attributes to types and
parameters as well. Some think like this:
class Bar
{
@not_null(Foo) bar (@custom int a) {}
}
Where @not_null is attached to Foo and @custom is attached to a.
Do you mean return type? I think your syntax has some serious
disadvantages. Consider parameters and multiple attributes.
For return types I'd like to see something like this:
@return: not_null
@return: MyAttr(foo)
Foo bar(@custom int a) {}
This is similar to C#'s [return: MyAttr]. Alternatively it might be:
@return(not_null)
@return(MyAttr(foo))
There's no need to attribute a return value. A) I think you're confusing it
with attributing *types* again, and B) you can just attribute the function
its self, and have access to precisely the same information.
You can't attribute a return value, since attributes aren't transferred
along with assignments, they are bound to their respective declaration.
Re: Custom attributes (again)
On Fri, 06 Apr 2012 03:54:15 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
What about type declarations? I think those ought to be supported too.
E.g. it
makes sense to mark an entire type as @attr(serializable) (or the
inverse).
That would make it a type constructor, not a storage class, which we
talked about earlier in the thread. I refer you to that discussion.
I think there is a huge misunderstanding here.
A type constructor alters a type. Annotations are not type constructors.
for example:
class C {}
@foo class D {}
@foo C c;
@foo2 D d;
D d2 = d;
In all these cases, the @foo or @foo2 affects the *declaration*, not the
*type*. So:
1. D's type is not affected, it's still class D. But an annotation has
been stored on the *symbol* D, such that it can be looked up later.
2. annotations on variables do *not* affect the type of the variable. The
assignment to d2 works fine.
3. The following symbols have annotations attached to them:
C: none
D: @foo
c: @foo
d: @foo2
d2: none
Note that d and d2 have no annotations attached even though they are of
type D. Because the type isn't affected by annotations.
An annotation is simply metadata, stored in the compiler, and looked up
via compiler directives. Optionally (and I would encourage this),
TypeInfo would store annotations on type declarations for retrieval at
runtime.
-Steve
Re: Custom attributes (again)
On 2012-04-06 14:31, Timon Gehr wrote: @not_null cannot be attached to Foo. It would have to create a new symbol @not_null(Foo). And then, all the concerns Walter has raised apply. Hmm, I guess. But it would be nice to have :) -- /Jacob Carlborg
Re: Custom attributes (again)
On 6 April 2012 15:58, Steven Schveighoffer schvei...@yahoo.com wrote:
On Fri, 06 Apr 2012 03:54:15 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 4/6/2012 12:49 AM, Alex Rønne Petersen wrote:
What about type declarations? I think those ought to be supported too.
E.g. it
makes sense to mark an entire type as @attr(serializable) (or the
inverse).
That would make it a type constructor, not a storage class, which we
talked about earlier in the thread. I refer you to that discussion.
I think there is a huge misunderstanding here.
A type constructor alters a type. Annotations are not type constructors.
for example:
class C {}
@foo class D {}
@foo C c;
@foo2 D d;
D d2 = d;
In all these cases, the @foo or @foo2 affects the *declaration*, not the
*type*. So:
1. D's type is not affected, it's still class D. But an annotation has
been stored on the *symbol* D, such that it can be looked up later.
2. annotations on variables do *not* affect the type of the variable. The
assignment to d2 works fine.
3. The following symbols have annotations attached to them:
C: none
D: @foo
c: @foo
d: @foo2
d2: none
Note that d and d2 have no annotations attached even though they are of
type D. Because the type isn't affected by annotations.
Just to clarify, typeof(d) and typeof(d2) (ie, both D's) are still
annotated with foo, right? This is precisely how I imagine it to be.
An annotation is simply metadata, stored in the compiler, and looked up via
compiler directives. Optionally (and I would encourage this), TypeInfo
would store annotations on type declarations for retrieval at runtime.
I agree, and I would also encourage this.
Re: Custom attributes (again)
On 6 April 2012 15:13, deadalnix deadal...@gmail.com wrote:
Le 06/04/2012 11:41, Johannes Pfau a écrit :
Am Fri, 06 Apr 2012 00:48:34 -0700
schrieb Walter
Brightnewshound2@digitalmars.**comnewshou...@digitalmars.com
:
On 4/6/2012 12:35 AM, Alex Rønne Petersen wrote:
It actually can be a problem. In .NET land, there are many
attributes across many projects (and even in the framework itself)
with the same names. It turns out that regular namespace lookup
rules alleviate this problem.
Perhaps a better scheme is:
enum foo = 3;
...
@attr(foo) int x;
That way, foo will follow all the usual rules.
The last time custom attributes where discussed, a C# like model was
proposed. Is there a good reason why we should deviate from the C#
implementation?
C#:
http://msdn.microsoft.com/en-**US/library/48zeb25s(v=vs.80).**aspxhttp://msdn.microsoft.com/en-US/library/48zeb25s(v=vs.80).aspx
http://msdn.microsoft.com/en-**US/library/sw480ze8(v=vs.100).**aspxhttp://msdn.microsoft.com/en-US/library/sw480ze8(v=vs.100).aspx
http://msdn.microsoft.com/en-**US/library/z919e8tw(v=vs.80).**aspxhttp://msdn.microsoft.com/en-US/library/z919e8tw(v=vs.80).aspx
(C# attributes can be applied to almost everything, therefore sometimes
disambiguating targets is necessary. Probably not needed in D):
http://msdn.microsoft.com/en-**US/library/b3787ac0(v=vs.80).**aspxhttp://msdn.microsoft.com/en-US/library/b3787ac0(v=vs.80).aspx
Syntax in D would be different of course, but I see absolutely no need
for the redundant (and ugly) @attr.
Declaring a custom attribute:
-
module std.something;
struct Author
{
string name;
public this(string name)
{
this.name = name;
}
}
-
Using it:
-
import std.something; //Usual namespace lookup rules apply to attributes
/*
* @Author(param) calls the constructor of the Author struct and
* attaches the struct instance to test. Probably @Author (without
* parenthesis) coud be made to mean std.something.Author.init
*/
@Author(Johannes Pfau) int test;
-
Attaching attributes multiple times as in C# should be possible.
Using reflection to get that attribute:
-
if(__traits(hasAttribute, test, std.something.Author))
{
Author[] authors = __traits(getAttribute, test,
std.something.Author);
}
-
An array is used here to support attaching the same attribute multiple
times. Of course auto authors = ... should be usable here too.
That is a really nice proposal !
This is precisely how I have always imagined the system working. Walter:
can you comment why you think this is not do-able, or not a good way to go
about it?
Re: Custom attributes (again)
On 2012-04-06 14:38, Piotr Szturmaj wrote:
Do you mean return type? I think your syntax has some serious
disadvantages. Consider parameters and multiple attributes.
For return types I'd like to see something like this:
@return: not_null
@return: MyAttr(foo)
Foo bar(@custom int a) {}
This is similar to C#'s [return: MyAttr]. Alternatively it might be:
@return(not_null)
@return(MyAttr(foo))
Hmm, or something like how Java does it. You attached this information
when you declare the attribute:
@Retention(RetentionPolicy.RUNTIME) // Make this annotation accessible
at runtime via reflection.
@Target({ElementType.METHOD}) // This annotation can only be applied
to class methods.
public @interface Tweezable {
}
Or with another syntax:
@attribute @target(type) struct not_null {}
--
/Jacob Carlborg
Re: Custom attributes (again)
On 2012-04-06 14:55, Manu wrote:
On 6 April 2012 15:38, Piotr Szturmaj bncr...@jadamspam.pl
mailto:bncr...@jadamspam.pl wrote:
Jacob Carlborg wrote:
I would like to have the possibility to attach attributes to
types and
parameters as well. Some think like this:
class Bar
{
@not_null(Foo) bar (@custom int a) {}
}
Where @not_null is attached to Foo and @custom is attached to a.
Do you mean return type? I think your syntax has some serious
disadvantages. Consider parameters and multiple attributes.
For return types I'd like to see something like this:
@return: not_null
@return: MyAttr(foo)
Foo bar(@custom int a) {}
This is similar to C#'s [return: MyAttr]. Alternatively it might be:
@return(not_null)
@return(MyAttr(foo))
There's no need to attribute a return value. A) I think you're confusing
it with attributing *types* again, and B) you can just attribute the
function its self, and have access to precisely the same information.
You can't attribute a return value, since attributes aren't transferred
along with assignments, they are bound to their respective declaration.
It depends on what we want out of attributes.
--
/Jacob Carlborg
Re: Custom attributes (again)
On 2012-04-06 14:58, Steven Schveighoffer wrote: An annotation is simply metadata, stored in the compiler, and looked up via compiler directives. Optionally (and I would encourage this), TypeInfo would store annotations on type declarations for retrieval at runtime. -Steve Yes, annotations/attributes should be accessible at both compile time and runtime. -- /Jacob Carlborg
custom attribute proposal (yeah, another one)
OK, so I woke up this morning to find a huge discussion on attributes, and
I'd like to once again propose the idea of how to define and use an
attribute.
I do not like the idea of:
@attr(identifier)
Why? Because what the hell did we create that @ syntax for? I though
it was to avoid misinterpreting such things as normal symbols, and avoid
creating new keywords. Why should the compiler be the only one able to
use such symbols?
Another thing I don't like is some idea that only a certain type of
construct can be the identifier. An attribute should have one requirement
-- that it can be created/determined at compile time.
So here is my proposal:
1. Introduce a new compiler-defined attribute @attribute (or @attr or
something better, the name isn't important).
2. This attribute can *only* be used on a module-level function.
3. @attribute functions *must* be CTFE-able.
4. An @attribute function can be used as a user-defined attribute on any
declaration using the syntax @identifier where identifier is the name of
the attribute function (subject to normal function lookup rules). If the
attribute can be called without parameters, the parentheses are optional.
5. When used on a declaration, that CTFE function is called during
compile-time, and the result of that function is stored as metadata on
that symbol. It does not affect the type of the symbol or transfer to any
other symbols that are assigned to the value of that declaration (in other
words, it *cannot* be used as a type constructor).
6. The metadata is stored in a key-value pair, with the key being the
symbol of the @attribute function, and the value being the result of the
CTFE function.
7. One can lookup whether an attribute exists on a symbol using
__traits(hasAttribute, symbol).
8. One can retrieve the value of the CTFE result using
__traits(getAttribute, symbol). If the CTFE function returns void, this
is a compiler error.
And that's it. We can extend this eventually to storing something in
TypeInfo, but I'm not sure we need that. However, I want to stress that
having runtime type metadata is not a requirement for this proposal.
Example usage:
@attribute bool serializable(bool yesorno = true) { return yesorno; }
unittest {
// serializable is a normal function also
assert(serializable() == true);
assert(serializable(true) == true);
assert(serializable(false) == false);
}
@serializable struct MyType
{
int x;
int y;
@serializable(false) int z;
}
string serialize(T)(const ref T t) if (__traits(hasAttribute,
serializable) __traits(getAttribute, serializable))
{
// serialize each field. Skip any fields that are marked as
serializable == false
}
-Steve
Re: Custom attributes (again)
On Fri, 06 Apr 2012 09:04:58 -0400, Manu turkey...@gmail.com wrote: On 6 April 2012 15:58, Steven Schveighoffer schvei...@yahoo.com wrote: Note that d and d2 have no annotations attached even though they are of type D. Because the type isn't affected by annotations. Just to clarify, typeof(d) and typeof(d2) (ie, both D's) are still annotated with foo, right? This is precisely how I imagine it to be. Correct. -Steve
uploading with curl
Hello guys,
I'm trying to use curl library to satisfy my file transfer needs
under Windows 7. I've spent all the day and the most of
functionality I have already tried works like a charm. But I have
a few issues with upload function.
First of all, if I try to use something like:
auto client = FTP(192.168.110.58);
or:
upload!FTP(file.zip, 192.168.110.58);
curl wrapper does not understand we are trying to use
ftp-protocol and uses http instead, returning something like:
?xml version=1.0 encoding=iso-8859-1?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en
lang=en
head
title400 - Bad Request/title
/head
body
h1400 - Bad Request/h1
/body
/html
Not a big deal, I'll use ftp://xx.xx.xx.xx; format everywhere
below.
Here is the code I'm trying to use to upload a local file to the
ftp-host with an authentication:
auto client = FTP();
client.setAuthentication(login, pass);
upload!FTP(file.zip, ftp://192.168.110.58/file.zip;,
client);
This will pass the authentication but won't upload the file.
Then I decided to take a look to the code of std.net.curl.upload
function and use a low-level API the same way to find the
solution. Here is what I got:
auto f = new std.stream.BufferedFile(file.zip, FileMode.In);
scope (exit) f.close();
auto client = FTP(ftp://192.168.110.58;);
client.verbose(true);
client.setAuthentication(login, pass);
client.onSend = (void[] data)
{
return f.read(cast(ubyte[])data);
};
client.contentLength = cast(size_t)f.size;
client.perform();
It's basically the same as upload function. This authenticates
correctly, gets directory listing and then nothing happens:
* Connection #0 to host 192.168.110.58 left intact
QUIT
221 Goodbye.
* Closing connection #0
And it looks correct for me, why should it upload any file!?
So I decided to replace the last line of the code with the
following:
client.addCommand(epsv);
client.addCommand(stor file.zip);
client.perform();
Here are the results:
epsv
229 Entering Extended Passive Mode (|||12761|)
stor file.zip
* FTP response timeout
* Connection #0 to host 192.168.110.58 left intact
* Timeout was reached
QUIT
* server response timeout
* Closing connection #0
std.net.curl.CurlTimeoutException@std\net\curl.d():
6B2BD8C6 on handle 166CB60
This way the file was created on the server, but it's empty. It
looks like client.onSend statements are never executed.
Unfortunately, I didn't managed to find out why, it's somewhere
in object private RefCounted!Impl p (curl.d:1956), but I didn't
find where it is.
So, what am I doing wrong? Does std.net.curl.upload work for you
correctly? How do I upload a file to the ftp-host with
authentication? What is RefCounted!Impl p and where do I find
it's p.curl.perform() method?
P.S.: Firewall is not the case, other ftp clients and
std.net.curl.download function work fine, rules for the program
are created (just in case).
Thank you in advance, any advice is really appreciated.
Re: Custom attributes (again)
On Friday, 6 April 2012 at 06:47:56 UTC, Walter Bright wrote: I was thinking of something along the lines of what has been proposed here earlier: @attr(identifier = expression) The identifier in there is a liability because of name conflicts. Instead, use typeof(expression) to identify it. Since two types can't have the same fully qualified name, it will never conflict. Jacob and I disagreed on some details, but both our proposals in the last thread had this in common. Java does it this way, too. Here's the other thread: http://forum.dlang.org/thread/bccwycoexxykfgxve...@forum.dlang.org
