www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Effective D book?

reply "Szymon Gatner" <noemail gmail.com> writes:
Any plans on that now that language is stable enough? Andrei 
authoring maybe?
Jun 14 2013
next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:

 Any plans on that now that language is stable enough? Andrei 
 authoring maybe?


The language is fairly stable, but still far from complete. 
There's still several unimplemented and undesigned big features 
that could significantly affects what the best practices are 
(scope parameters and lack of copy constructors comes to mind).

Also, I think it's still a bit too early to put out a book on 
best practices in D. Not many people have lots of experience 
writing production D code.
Jun 14 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 8:56 AM, Peter Alexander wrote:

 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:

 Any plans on that now that language is stable enough? Andrei authoring maybe?


 The language is fairly stable, but still far from complete. There's still
 several unimplemented and undesigned big features that could significantly
 affects what the best practices are (scope parameters and lack of copy
 constructors comes to mind).

 Also, I think it's still a bit too early to put out a book on best practices in
 D. Not many people have lots of experience writing production D code.


It's true that "best practices" in D are still evolving. That's not a bad thing 
- best practices in C++ have changed a lot over the years.
Jun 14 2013
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:

 Any plans on that now that language is stable enough? Andrei 
 authoring maybe?


Who would write it?

It seems to me that D is still new and not widespread, which 
means that everybody has their own styles and interpretation of 
how to use the language.

I could see someone writing a "Programming with Phobos" book(let) 
though, for example. But a full blown best practice for the 
entire language itself seems excessive to me. In particular, 
while *stable*, it *is* still "evolving", which means that while 
the old code still works, the patterns are still shifting.
Jun 14 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 11:29 AM, monarch_dodra wrote:

 Who would write it?


Anyone who wants to!


 It seems to me that D is still new and not widespread, which means that
 everybody has their own styles and interpretation of how to use the language.

 I could see someone writing a "Programming with Phobos" book(let) though, for
 example. But a full blown best practice for the entire language itself seems
 excessive to me. In particular, while *stable*, it *is* still "evolving", which
 means that while the old code still works, the patterns are still shifting.


Although you are right, the best practices are still evolving, I don't think 
that automatically precludes writing a book on the current state of thought on 
the matter.
Jun 14 2013
prev sibling next sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 14 June 2013 at 18:29:10 UTC, monarch_dodra wrote:

 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:

 Any plans on that now that language is stable enough? Andrei 
 authoring maybe?


 Who would write it?


Did you read what you quoted? :-)
Jun 14 2013
next sibling parent "Szymon Gatner" <noemail gmail.com> writes:
On Friday, 14 June 2013 at 19:38:10 UTC, Peter Alexander wrote:

 On Friday, 14 June 2013 at 18:29:10 UTC, monarch_dodra wrote:

 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:

 Any plans on that now that language is stable enough? Andrei 
 authoring maybe?


 Who would write it?


 Did you read what you quoted? :-)


That was just a suggestion of course ;) And I am asking this 
after watching David Simcha's talk. There are language idioms 
clarifying already even if just while writing Phobos. And there 
can always be new editions with newly discovered idioms / 
patterns and good practices. But I do see your point on proper 
battlefield testing first.
Jun 14 2013
prev sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 14 June 2013 at 19:38:10 UTC, Peter Alexander wrote:

 On Friday, 14 June 2013 at 18:29:10 UTC, monarch_dodra wrote:

 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:

 Any plans on that now that language is stable enough? Andrei 
 authoring maybe?


 Who would write it?


 Did you read what you quoted? :-)


I guess it does look silly like that :)

But the point I wanted to make came in the next sentence, is that 
I think that currently, no single person could write said book, 
because everyone has their own interpretation of best practices, 
or different types of use. Not even Andrei. We all have our own 
interpretation right now of how to use D. If the book was 
released by a single author, it would just be that person's 
interpretation of "Effective".

I would love to be proven wrong of course.

Another interesting project, given D's state, could be a 
collaborative "D idioms and patterns", for example?
Jun 14 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jun 14, 2013 at 11:22:14PM +0200, monarch_dodra wrote:

 On Friday, 14 June 2013 at 19:38:10 UTC, Peter Alexander wrote:

On Friday, 14 June 2013 at 18:29:10 UTC, monarch_dodra wrote:

On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:

Any plans on that now that language is stable enough? Andrei
authoring maybe?


Who would write it?


Did you read what you quoted? :-)


 
 I guess it does look silly like that :)
 
 But the point I wanted to make came in the next sentence, is that I
 think that currently, no single person could write said book,
 because everyone has their own interpretation of best practices, or
 different types of use. Not even Andrei. We all have our own
 interpretation right now of how to use D. If the book was released
 by a single author, it would just be that person's interpretation of
 "Effective".
 
 I would love to be proven wrong of course.


What about collecting the most common D practices among us and seeing if
some common trends show up?



 Another interesting project, given D's state, could be a
 collaborative "D idioms and patterns", for example?


Isn't there already a section on the wiki dedicated to that? It would
help if more people would contribute their experiences.


T

-- 
When solving a problem, take care that you do not become part of the problem.
Jun 14 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 11:29 AM, monarch_dodra wrote:

 In particular, while *stable*, it *is* still "evolving", which
 means that while the old code still works, the patterns are still shifting.


One example of that is Andrei and I have been discussing the idea of moving 
import declarations from their traditional place at the top of the file to
being 
in the most nested scope in which they are referenced.
Jun 14 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2013 03:02 AM, Walter Bright wrote:

 On 6/14/2013 11:29 AM, monarch_dodra wrote:

 In particular, while *stable*, it *is* still "evolving", which
 means that while the old code still works, the patterns are still
 shifting.


 One example of that is Andrei and I have been discussing the idea of
 moving import declarations from their traditional place at the top of
 the file to being in the most nested scope in which they are referenced.


One issue with local imports is that they hide local symbols.
Jun 15 2013
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:

 One issue with local imports is that they hide local symbols.


Can you give an example? I can't repro.

void main()
{
	import std.stdio;
	void writeln(string) {}
	writeln("foo");
	std.stdio.writeln("bar");
}

This writes only "bar".
Jun 15 2013
next sibling parent reply "Mr. Anonymous" <mailnew4ster gmail.com> writes:
On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander wrote:

 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:

 One issue with local imports is that they hide local symbols.


 Can you give an example? I can't repro.

 void main()
 {
 	import std.stdio;
 	void writeln(string) {}
 	writeln("foo");
 	std.stdio.writeln("bar");
 }

 This writes only "bar".


void writeln(string) {}
void main()
{
	import std.stdio;
	writeln("foo");
	std.stdio.writeln("bar");
}

?
Jun 15 2013
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 15 June 2013 at 15:29:23 UTC, Mr. Anonymous wrote:

 On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander 
 wrote:

 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:

 One issue with local imports is that they hide local symbols.


 Can you give an example? I can't repro.

 void main()
 {
 	import std.stdio;
 	void writeln(string) {}
 	writeln("foo");
 	std.stdio.writeln("bar");
 }

 This writes only "bar".


 void writeln(string) {}
 void main()
 {
 	import std.stdio;
 	writeln("foo");
 	std.stdio.writeln("bar");
 }


Oh, but that's not a local symbol, that's a module level symbol. 
The import is more local that the module level writeln, so that 
works as you would expect.

It also isn't a problem at all, because you can easily refer to 
the module level symbol by fully qualifying it.

module thismodule;
void writeln(string) {}
void main()
{
	import std.stdio;
	thismodule.writeln("foo");
	std.stdio.writeln("bar");
}

In any case, I'd recommend explicitly choosing which symbols to 
import in the local import to avoid name clashes.
Jun 15 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2013 06:06 PM, Peter Alexander wrote:

 On Saturday, 15 June 2013 at 15:29:23 UTC, Mr. Anonymous wrote:

 On Saturday, 15 June 2013 at 15:09:55 UTC, Peter Alexander wrote:

 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:

 One issue with local imports is that they hide local symbols.


 Can you give an example? I can't repro.

 void main()
 {
     import std.stdio;
     void writeln(string) {}
     writeln("foo");
     std.stdio.writeln("bar");
 }

 This writes only "bar".


 void writeln(string) {}
 void main()
 {
     import std.stdio;
     writeln("foo");
     std.stdio.writeln("bar");
 }


 Oh, but that's not a local symbol, that's a module level symbol. The
 import is more local that the module level writeln, so that works as you
 would expect.

 It also isn't a problem at all, ...


It sure is, the module system is supposed to provide hijacking protection.
Jun 15 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/15/2013 2:34 PM, Timon Gehr wrote:

 It sure is, the module system is supposed to provide hijacking protection.


Inner scopes override outer scopes. That isn't what hijacking is.
Jun 15 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2013 01:36 AM, Walter Bright wrote:

 On 6/15/2013 2:34 PM, Timon Gehr wrote:

 It sure is, the module system is supposed to provide hijacking
 protection.


 Inner scopes override outer scopes. That isn't what hijacking is.


A module can introduce a new symbol and silently change what some 
identifier lookup refers to, where the previous symbol referred to 
resides in a different module.
Jun 15 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 16 June 2013 at 00:42:15 UTC, Timon Gehr wrote:

 On 06/16/2013 01:36 AM, Walter Bright wrote:

 On 6/15/2013 2:34 PM, Timon Gehr wrote:

 It sure is, the module system is supposed to provide hijacking
 protection.


 Inner scopes override outer scopes. That isn't what hijacking 
 is.


 A module can introduce a new symbol and silently change what 
 some identifier lookup refers to, where the previous symbol 
 referred to resides in a different module.


It happen to me recently; the bug was very puzzling. I do think 
that identifier lookup should turtle down in the module before 
looking at imports.
Jun 15 2013
prev sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 15 June 2013 at 23:36:35 UTC, Walter Bright wrote:

 On 6/15/2013 2:34 PM, Timon Gehr wrote:

 It sure is, the module system is supposed to provide hijacking 
 protection.


 Inner scopes override outer scopes. That isn't what hijacking 
 is.


I think this is an issue Walter, consider:

void main()
{
     import std.stdio;
     string message = "Hello, world!";
     writeln(message);
}

It std.stdio contains a symbol called "message" then this will 
not print "Hello, world". Updates to libraries that introduce 
symbols could subtly break working code.

Whether or not this is what hijacking is, I think this is a 
problem.
Jun 16 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 16, 2013 11:06:18 Peter Alexander wrote:

 On Saturday, 15 June 2013 at 23:36:35 UTC, Walter Bright wrote:

 On 6/15/2013 2:34 PM, Timon Gehr wrote:

 It sure is, the module system is supposed to provide hijacking
 protection.


 
 Inner scopes override outer scopes. That isn't what hijacking
 is.


 
 I think this is an issue Walter, consider:
 
 void main()
 {
      import std.stdio;
      string message = "Hello, world!";
      writeln(message);
 }
 
 It std.stdio contains a symbol called "message" then this will
 not print "Hello, world". Updates to libraries that introduce
 symbols could subtly break working code.
 
 Whether or not this is what hijacking is, I think this is a
 problem.


I concur. It may be that it's reasonable for local imports to shadow 
declarations from outside the function rather than creating conflicts, but they 
definitely shouldn't shadow symbols inside the function - _especially_ when the 
local symbol is declared after the local import. The current behavior is just 
going to create bugs.

- Jonathan M Davis
Jun 16 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2013 2:06 AM, Peter Alexander wrote:

 On Saturday, 15 June 2013 at 23:36:35 UTC, Walter Bright wrote:

 On 6/15/2013 2:34 PM, Timon Gehr wrote:

 It sure is, the module system is supposed to provide hijacking protection.


 Inner scopes override outer scopes. That isn't what hijacking is.


 I think this is an issue Walter, consider:

 void main()
 {
      import std.stdio;
      string message = "Hello, world!";
      writeln(message);
 }

 It std.stdio contains a symbol called "message" then this will not print
"Hello,
 world".


Yes, it will. Current scope overrides imported scope.
Jun 16 2013
parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 16 June 2013 at 16:48:46 UTC, Walter Bright wrote:

 On 6/16/2013 2:06 AM, Peter Alexander wrote:

 It std.stdio contains a symbol called "message" then this will 
 not print "Hello,
 world".


 Yes, it will. Current scope overrides imported scope.


Sorry, bad example:

string message = "Hello, world!";
void main()
{
     import std.stdio;
     writeln(message);
}
Jun 16 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2013 05:09 PM, Peter Alexander wrote:

 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:

 One issue with local imports is that they hide local symbols.


 Can you give an example? I can't repro.

 void main()
 {
      import std.stdio;
      void writeln(string) {}
      writeln("foo");
      std.stdio.writeln("bar");
 }

 This writes only "bar".


So does this:

void main(){
     void writeln(string) {}
     writeln("foo");
     {
         import std.stdio;
         writeln("bar");
     }
}
Jun 15 2013
parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Saturday, 15 June 2013 at 21:30:50 UTC, Timon Gehr wrote:

 So does this:

 void main(){
     void writeln(string) {}
     writeln("foo");
     {
         import std.stdio;
         writeln("bar");
     }
 }


Still not seeing any issue. The first writeln cannot know about 
the import because it is at a deeper scope, so only the second 
writeln will print anything.



 It also isn't a problem at all, ...


 It sure is, the module system is supposed to provide hijacking 
 protection.


Hmm good point.



 More peculiar example:
 ...
 'writefx' happens to be a private symbol in std.stdio.


I think this is just the separate bug where private symbols are 
visible through imports. Should be solved by DIP22 IIRC.
Jun 16 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2013 11:03 AM, Peter Alexander wrote:

 On Saturday, 15 June 2013 at 21:30:50 UTC, Timon Gehr wrote:

 So does this:

 void main(){
     void writeln(string) {}
     writeln("foo");
     {
         import std.stdio;
         writeln("bar");
     }
 }


 Still not seeing any issue. The first writeln cannot know about the
 import because it is at a deeper scope, so only the second writeln will
 print anything.


...

The local import therefore hides a local symbol.
Jun 16 2013
next sibling parent reply "Tyro[17]" <ridimz yahoo.com> writes:
On 6/16/13 5:34 AM, Timon Gehr wrote:

 void main(){
      void writeln(string) {}
      writeln("foo");
      {
          import std.stdio;
          writeln("bar");
      }
 }


void main(){
     void writeln(string) {}
     writeln("foo");
     {
         import io = std.stdio;
         writeln("bar");
         io.writeln("baz");
     }
}

I see your point... but somehow I don't think it's that big of a 
problem. Should be fixed for those not willing to use the mechanism 
currently available to resolve the issue, but I wouldn't loose any sleep 
if it weren't.

-- 

Andrew Edwards
--------------------
http://www.akeron.co
auto getAddress() {
     string location = " ", period = ".";
     return ("info" ~ location ~ "afidem" ~ period ~ "org");
}
Jun 16 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/16/2013 11:50 AM, Tyro[17] wrote:

 On 6/16/13 5:34 AM, Timon Gehr wrote:

 void main(){
      void writeln(string) {}
      writeln("foo");
      {
          import std.stdio;
          writeln("bar");
      }
 }


 void main(){
      void writeln(string) {}
      writeln("foo");
      {
          import io = std.stdio;
          writeln("bar");
          io.writeln("baz");
      }
 }

 I see your point... but somehow I don't think it's that big of a
 problem.


Well, it does not have to be in order to get fixed. The D module system 
otherwise avoids this kind of issue.


 Should be fixed for those not willing to use the mechanism
 currently available to resolve the issue, but I wouldn't loose any sleep
 if it weren't.


There is no mechanism in place that reliably avoids silent breakage.
Jun 16 2013
parent "Tyro[17]" <ridimz yahoo.com> writes:
On 6/16/13 6:07 AM, Timon Gehr wrote:

 On 06/16/2013 11:50 AM, Tyro[17] wrote:

 On 6/16/13 5:34 AM, Timon Gehr wrote:





 Should be fixed for those not willing to use the mechanism
 currently available to resolve the issue, but I wouldn't loose any sleep
 if it weren't.


 There is no mechanism in place that reliably avoids silent breakage.


A very valid point. For this particular case though, I would move to 
suggest that an apt resolution would be to documentation the behavior 
and suggest that if such behavior is not desired, the use of renamed 
imports or static imports is recommended for scoped imports.

	import s = std.stdio;
	import std.stdio: print = writeln;
	static import std.stdio;

any of these options is a valid solution this particular issue while 
documentation takes care of the rest.

Having just said that, I took a quick look at the documentation and this 
is what it had to say:

"In function scopes, imported symbols only become visible after the 
import declaration lexically appears in the function body. In other 
words, imported symbols at function scope cannot be forward referenced. "

Even the example given there clearly tells you this will happen:

void main() {
	void writeln(string) {}
	void foo() {
		writeln("bar"); // calls main.writeln
		import std.stdio;
		writeln("bar"); // calls std.stdio.writeln
		void writeln(string) {}
		writeln("bar"); // calls main.foo.writeln
	}
	writeln("bar"); // calls main.writeln
	std.stdio.writeln("bar"); // error, std is undefined
}

I don't see the problem.

-- 

Andrew Edwards
--------------------
http://www.akeron.co
auto getAddress() {
     string location = " ", period = ".";
     return ("info" ~ location ~ "afidem" ~ period ~ "org");
}
Jun 16 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/16/13 5:34 AM, Timon Gehr wrote:

 On 06/16/2013 11:03 AM, Peter Alexander wrote:

 On Saturday, 15 June 2013 at 21:30:50 UTC, Timon Gehr wrote:

 So does this:

 void main(){
 void writeln(string) {}
 writeln("foo");
 {
 import std.stdio;
 writeln("bar");
 }
 }


 Still not seeing any issue. The first writeln cannot know about the
 import because it is at a deeper scope, so only the second writeln will
 print anything.


 ...

 The local import therefore hides a local symbol.


Yah that's a bug. Has anyone filed it yet?

Andrei
Jun 16 2013
parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Sunday, 16 June 2013 at 12:52:52 UTC, Andrei Alexandrescu 
wrote:

 On 6/16/13 5:34 AM, Timon Gehr wrote:

 The local import therefore hides a local symbol.


 Yah that's a bug. Has anyone filed it yet?


Timon has filed that the behaviour is underspecified:

http://d.puremagic.com/issues/show_bug.cgi?id=7329

I have now filed it as a bug:

http://d.puremagic.com/issues/show_bug.cgi?id=10378
Jun 16 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 06/15/2013 05:09 PM, Peter Alexander wrote:

 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:

 One issue with local imports is that they hide local symbols.


 Can you give an example? I can't repro.

 void main()
 {
      import std.stdio;
      void writeln(string) {}
      writeln("foo");
      std.stdio.writeln("bar");
 }

 This writes only "bar".


More peculiar example:

void main(){
     import std.stdio;
     void writefx(string s){writeln(s);}
     {
         import std.stdio;
         writefx("bar"); // error: writefx is private
     }
}

'writefx' happens to be a private symbol in std.stdio.
Jun 15 2013
parent "David Nadlinger" <code klickverbot.at> writes:
On Saturday, 15 June 2013 at 21:35:20 UTC, Timon Gehr wrote:

 On 06/15/2013 05:09 PM, Peter Alexander wrote:

 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:

 One issue with local imports is that they hide local symbols.


 Can you give an example? I can't repro.

 void main()
 {
     import std.stdio;
     void writeln(string) {}
     writeln("foo");
     std.stdio.writeln("bar");
 }

 This writes only "bar".


 More peculiar example:

 void main(){
     import std.stdio;
     void writefx(string s){writeln(s);}
     {
         import std.stdio;
         writefx("bar"); // error: writefx is private
     }
 }

 'writefx' happens to be a private symbol in std.stdio.


You might want to open a bug report for this.

David
Jun 15 2013
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 15.06.2013 17:09, Peter Alexander wrote:

 On Saturday, 15 June 2013 at 12:20:46 UTC, Timon Gehr wrote:

 One issue with local imports is that they hide local symbols.


 Can you give an example? I can't repro.


Here is another example I recently stumbled upon:

/////////
module a;

class A
{
	import std.stdio;
}

/////////
module b;

void writeln(string){}

class B : A
{
	void foo()
	{
		writeln("Hi");
	}
}

Guess which function is called in foo!

There are conflicting rule sets at work here, the symbol lookup rules 
for base classes vs the lookup rules for (private) imports.

Walter seems to be fine as is but I'm not sure 
(http://forum.dlang.org/post/5197E695.10807 digitalmars.com - the issue 
is not a regression as reported, there seems to be some change to it in 
2.063 that I couldn't isolate). At least the symbols imported into the 
base class should be private by default (though that won't change 
anything in the same module).

OT: This points to another slight non-orthogonality as declarations and 
imports have different visibility defaults, which is modified by the 
same "public:"/"private:".
Jun 16 2013
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, June 14, 2013 20:29:09 monarch_dodra wrote:

 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:

 Any plans on that now that language is stable enough? Andrei
 authoring maybe?


 
 Who would write it?


I'm a bit reticent to bring it up given that I won't be done anytime soon, but 
I actually started writing such a book following DConf. After Andrew brought 
up the possibility of Effective D in his talk and all of the talk that occurred 
at DConf about doing more with tutorials and publishing best practices, I 
decided that I'd give it shot.

And while I'm sure that there's plenty more best practices that we'll figure 
out over time, and some of what we do know has been shifting as we learn, I 
think that we do know enough at this point about best practices in D to fill 
such a book.

Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc 
so that it can easily be converted into latex, html, and e-book formats rather 
than being tied to any particular format (I was going to use latex, but Andrei
thought that a macro language would be better as latex is very tied to physical
print and fixed layouts). It'll probably be the first book ever to be written
entirely in ddoc.

- Jonathan M Davis
Jun 14 2013
next sibling parent "Elvis" <nospam pureworld.com> writes:
On Saturday, 15 June 2013 at 02:17:59 UTC, Jonathan M Davis wrote:

 On Friday, June 14, 2013 20:29:09 monarch_dodra wrote:

 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:

 Any plans on that now that language is stable enough? Andrei
 authoring maybe?


 
 Who would write it?


 I'm a bit reticent to bring it up given that I won't be done 
 anytime soon, but
 I actually started writing such a book following DConf. After 
 Andrew brought
 up the possibility of Effective D in his talk and all of the 
 talk that occurred
 at DConf about doing more with tutorials and publishing best 
 practices, I
 decided that I'd give it shot.

 And while I'm sure that there's plenty more best practices that 
 we'll figure
 out over time, and some of what we do know has been shifting as 
 we learn, I
 think that we do know enough at this point about best practices 
 in D to fill
 such a book.

 Interestingly enough, based on Andrei's suggestions, I'm 
 writing it using ddoc
 so that it can easily be converted into latex, html, and e-book 
 formats rather
 than being tied to any particular format (I was going to use 
 latex, but Andrei
 thought that a macro language would be better as latex is very 
 tied to physical
 print and fixed layouts). It'll probably be the first book ever 
 to be written
 entirely in ddoc.

 - Jonathan M Davis


Good jobs, I'm very much looking forward to reading it!
Jun 14 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 7:17 PM, Jonathan M Davis wrote:

 I'm a bit reticent to bring it up given that I won't be done anytime soon, but
 I actually started writing such a book following DConf. After Andrew brought
 up the possibility of Effective D in his talk and all of the talk that occurred
 at DConf about doing more with tutorials and publishing best practices, I
 decided that I'd give it shot.


Awesome!


 And while I'm sure that there's plenty more best practices that we'll figure
 out over time, and some of what we do know has been shifting as we learn, I
 think that we do know enough at this point about best practices in D to fill
 such a book.


Keep us posted.



 Interestingly enough, based on Andrei's suggestions, I'm writing it using ddoc
 so that it can easily be converted into latex, html, and e-book formats rather
 than being tied to any particular format (I was going to use latex, but Andrei
 thought that a macro language would be better as latex is very tied to physical
 print and fixed layouts). It'll probably be the first book ever to be written
 entirely in ddoc.


This is just being a win all around!
Jun 14 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, June 14, 2013 19:57:52 Walter Bright wrote:

 Interestingly enough, based on Andrei's suggestions, I'm writing it using
 ddoc so that it can easily be converted into latex, html, and e-book
 formats rather than being tied to any particular format (I was going to
 use latex, but Andrei thought that a macro language would be better as
 latex is very tied to physical print and fixed layouts). It'll probably
 be the first book ever to be written entirely in ddoc.


 
 This is just being a win all around!


My one major complaint about using ddoc is the need for the $(P ) macro 
everywhere, whereas LaTeX inserts paragraphs based on empty lines. I should 
probably create an enhancement request for that (and maybe even try and 
implement it), but I have enough to do right now that I decided that I'd just 
put up with it for now. But aside from the need for $(P ) macros, it's
actually quite pleasant to work with.

I do have to process the ddoc before giving it to the compiler in order to
generate the table of contents and index macros (since you can't generate
those with just macros), but since I'm using a D script to do the build,
that was actually pretty easy.

So, I'm writing a book on D which is written in D's documentation macro
language and using D to actually drive the build. It's all very D. :)

- Jonathan M Davis
Jun 14 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 8:15 PM, Jonathan M Davis wrote:

 My one major complaint about using ddoc is the need for the $(P ) macro
 everywhere, whereas LaTeX inserts paragraphs based on empty lines. I should
 probably create an enhancement request for that (and maybe even try and
 implement it), but I have enough to do right now that I decided that I'd just
 put up with it for now. But aside from the need for $(P ) macros, it's
 actually quite pleasant to work with.

 I do have to process the ddoc before giving it to the compiler in order to
 generate the table of contents and index macros (since you can't generate
 those with just macros), but since I'm using a D script to do the build,
 that was actually pretty easy.

 So, I'm writing a book on D which is written in D's documentation macro
 language and using D to actually drive the build. It's all very D. :)


I'd write it first without bothering with any formatting commands. Add them in 
at the end. (This is how I do all my articles.)
Jun 14 2013
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jun 14, 2013 at 11:15:14PM -0400, Jonathan M Davis wrote:

 On Friday, June 14, 2013 19:57:52 Walter Bright wrote:

 Interestingly enough, based on Andrei's suggestions, I'm writing
 it using ddoc so that it can easily be converted into latex, html,
 and e-book formats rather than being tied to any particular format
 (I was going to use latex, but Andrei thought that a macro
 language would be better as latex is very tied to physical print
 and fixed layouts). It'll probably be the first book ever to be
 written entirely in ddoc.


 
 This is just being a win all around!


 
 My one major complaint about using ddoc is the need for the $(P )
 macro everywhere, whereas LaTeX inserts paragraphs based on empty
 lines. I should probably create an enhancement request for that (and
 maybe even try and implement it), but I have enough to do right now
 that I decided that I'd just put up with it for now. But aside from
 the need for $(P ) macros, it's actually quite pleasant to work with.


I'm curious about how you manage to factor out / abstract away the
niggling details of LaTeX, like the use of ".\ " after an abbreviation
(to make it produce only an inter-word space, as opposed to the extra
space at the end of a sentence), m-dash vs. n-dash, etc., some of which
are quite specific to LaTeX but are quite necessary if you're going for
print-quality typesetting. And what about embedded \footnote's? Section
references? Do you have macros for all of them? Does it make it a bit
cumbersome to type?



 I do have to process the ddoc before giving it to the compiler in
 order to generate the table of contents and index macros (since you
 can't generate those with just macros), but since I'm using a D script
 to do the build, that was actually pretty easy.


[...]

Isn't \tableofcontents enough to auto-generate the table of contents? Or
are you talking about doing that for HTML output?


T

-- 
Talk is cheap. Whining is actually free. -- Lars Wirzenius
Jun 15 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/15/13 11:55 AM, H. S. Teoh wrote:

 I'm curious about how you manage to factor out / abstract away the
 niggling details of LaTeX, like the use of ".\ " after an abbreviation
 (to make it produce only an inter-word space, as opposed to the extra
 space at the end of a sentence),


ABBRDOT = .\$(SPACE)


 m-dash


MDASH = ---


 vs. n-dash


NDASH = --


, etc., some of which
 are quite specific to LaTeX but are quite necessary if you're going for
 print-quality typesetting. And what about embedded \footnote's?


FOOTNOTE = \footnote{$0}


 Section
 references?


SECREF = \ref{sec:$0}


 Do you have macros for all of them?


Yah. All of the above would go into a latex.ddoc macros file. Then the 
html.ddoc file would contain things like

ABBRDOT = .$(SPACE)
MDASH = &mdash;
etc.


 Does it make it a bit
 cumbersome to type?


Most likely, but this is the price to pay for supporting multiple 
formats. Then, LaTeX wasn't exactly designed for ease of typing, so the 
marginal cumbersomeness shouldn't be high.


 I do have to process the ddoc before giving it to the compiler in
 order to generate the table of contents and index macros (since you
 can't generate those with just macros), but since I'm using a D script
 to do the build, that was actually pretty easy.


 [...]

 Isn't \tableofcontents enough to auto-generate the table of contents? Or
 are you talking about doing that for HTML output?


Yah, all outputs should have TOCs and such.


Andrei
Jun 16 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jun 16, 2013 at 07:58:20AM -0400, Andrei Alexandrescu wrote:

 On 6/15/13 11:55 AM, H. S. Teoh wrote:

I'm curious about how you manage to factor out / abstract away the
niggling details of LaTeX, like the use of ".\ " after an
abbreviation (to make it produce only an inter-word space, as opposed
to the extra space at the end of a sentence),


 
 ABBRDOT = .\$(SPACE)
 

m-dash


 
 MDASH = ---
 

vs. n-dash


 
 NDASH = --
 

, etc., some of which are quite specific to LaTeX but are quite
necessary if you're going for print-quality typesetting. And what
about embedded \footnote's?


 
 FOOTNOTE = \footnote{$0}


But it doesn't address the problem of how to make $(FOOTNOTE ...) work
correctly with HTML output. Is it suppressed completely? Post-processed
to appear in a footnote DIV? Something else?



Section references?


 
 SECREF = \ref{sec:$0}
 

Do you have macros for all of them?


 
 Yah. All of the above would go into a latex.ddoc macros file. Then
 the html.ddoc file would contain things like
 
 ABBRDOT = .$(SPACE)
 MDASH = &mdash;
 etc.
 

Does it make it a bit cumbersome to type?


 
 Most likely, but this is the price to pay for supporting multiple
 formats. Then, LaTeX wasn't exactly designed for ease of typing, so
 the marginal cumbersomeness shouldn't be high.


[...]

Or rather, LaTeX *was* designed for ease of typing, but not for ease of
auto-generation / parsing. Many of the quirks of LaTeX syntax is to make
it easy to type certain formatting elements, but it comes at the expense
of consistency of syntax, which is what makes it tricky for systems like
DDoc to generate output for (and rather hard for external programs to
parse correctly).


T

-- 
This is a tpyo.
Jun 16 2013
prev sibling next sibling parent reply "Szymon Gatner" <noemail gmail.com> writes:
On Saturday, 15 June 2013 at 02:17:59 UTC, Jonathan M Davis wrote:

 On Friday, June 14, 2013 20:29:09 monarch_dodra wrote:

 On Friday, 14 June 2013 at 15:38:02 UTC, Szymon Gatner wrote:

 Any plans on that now that language is stable enough? Andrei
 authoring maybe?


 
 Who would write it?


 I'm a bit reticent to bring it up given that I won't be done 
 anytime soon, but
 I actually started writing such a book following DConf. After 
 Andrew brought
 up the possibility of Effective D in his talk and all of the 
 talk that occurred
 at DConf about doing more with tutorials and publishing best 
 practices, I
 decided that I'd give it shot.

 And while I'm sure that there's plenty more best practices that 
 we'll figure
 out over time, and some of what we do know has been shifting as 
 we learn, I
 think that we do know enough at this point about best practices 
 in D to fill
 such a book.

 Interestingly enough, based on Andrei's suggestions, I'm 
 writing it using ddoc
 so that it can easily be converted into latex, html, and e-book 
 formats rather
 than being tied to any particular format (I was going to use 
 latex, but Andrei
 thought that a macro language would be better as latex is very 
 tied to physical
 print and fixed layouts). It'll probably be the first book ever 
 to be written
 entirely in ddoc.

 - Jonathan M Davis


Would love to proof read it.

Btw: Not sure if "effective" series isn't somehow propertiary and 
linked to Herb Sutter. I know he is not only responsible for c++
Jun 14 2013
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, June 15, 2013 05:43:11 Szymon Gatner wrote:

 Btw: Not sure if "effective" series isn't somehow propertiary and
 linked to Herb Sutter. I know he is not only responsible for c++




wrote the Javae one. I'm not aware of Herb Sutter having anything to do with 
any of them. And Effective Java was published via a different publisher from
the 
other two, so my guess is that there would be no problem with the name 
Effective D. But I'm not married to the name "Effective D." It's simply the
name 
that's been suggested and which would have recognition thanks to books with 
similar names in other languages. The important thing is the content of the 
book. If it ends up with a different name, then it ends up with a different 
name.

- Jonathan M Davis
Jun 14 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/14/2013 8:43 PM, Szymon Gatner wrote:

 Btw: Not sure if "effective" series isn't somehow propertiary and linked to
Herb



I would refrain from naming it "Effective D". Scott Meyers is the author of 
several "Effective C++" books, and it would be disrespectful to try to trade
off 
of that, even though there is an "Effective Java" by Bloch and an "Effective

by Wagner, etc.

Heck, to throw something out there, why not "D Best Practices"?
Jun 14 2013
parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote:

 Heck, to throw something out there, why not "D Best Practices"?


Or "D Patterns and Practices" ?
With some David Simcha content in it (if he agrees with that of 
course).
Jun 15 2013
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
15-Jun-2013 12:07, SomeDude пишет:

 On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote:

 Heck, to throw something out there, why not "D Best Practices"?


 Or "D Patterns and Practices" ?
 With some David Simcha content in it (if he agrees with that of course).


IMHO D Cookbook sounds about right.

-- 
Dmitry Olshansky
Jun 15 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 16, 2013 01:55:35 Dmitry Olshansky wrote:

 15-Jun-2013 12:07, SomeDude =D0=BF=D0=B8=D1=88=D0=B5=D1=82:

 On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote:

 Heck, to throw something out there, why not "D Best Practices"?


=20
 Or "D Patterns and Practices" ?
 With some David Simcha content in it (if he agrees with that of cou=




rse).

=20
 IMHO D Cookbook sounds about right.


Cookbook is in a similar situation with Effective, if not worse, as O'R=
eilly=20
has a whole line of programming books with that name, and AFAIK, every=20=

programming book with Cookbook in its name has been published though th=
em. So,=20
an author who wanted to use that title would probably have to publish=20=

specifically through O'Reilly to get it into that series.

However, from the looks of how the Cookbook books are supposed to be la=
id out,=20
they really aren't intended for discussing best practices. They're for =
giving=20
solutions to specific programming problems, with the idea that they con=
tain a=20
list of such "recipes" that you can look up to figure out how to solve =
common=20
programming problems in the language or domain that the book covers. It=
 would=20
certainly be useful to have that sort of book for D, but I believe that=
 it=20
would be fundamentally different from what a book which might be publis=
hed in=20
the "Effective" series would contain.

For the book that I'm working on, I'm really not going to worry about t=
he=20
title at this point. I'm just going to write it, and I'll worry about s=
tuff=20
like the title and who might publish it or anything along those lines o=
nce=20
it's much closer to completion.

- Jonathan M Davis
Jun 15 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/15/13 6:19 PM, Jonathan M Davis wrote:

 For the book that I'm working on, I'm really not going to worry about the
 title at this point. I'm just going to write it, and I'll worry about stuff
 like the title and who might publish it or anything along those lines once
 it's much closer to completion.


Awesome approach.

Andrei
Jun 16 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/15/2013 3:19 PM, Jonathan M Davis wrote:

 For the book that I'm working on, I'm really not going to worry about the
 title at this point. I'm just going to write it, and I'll worry about stuff
 like the title and who might publish it or anything along those lines once
 it's much closer to completion.


+1

Also, I wouldn't worry about formatting until it's near completion, either.
Jun 16 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/16/13 12:53 PM, Walter Bright wrote:

 On 6/15/2013 3:19 PM, Jonathan M Davis wrote:

 For the book that I'm working on, I'm really not going to worry about the
 title at this point. I'm just going to write it, and I'll worry about
 stuff
 like the title and who might publish it or anything along those lines
 once
 it's much closer to completion.


 +1

 Also, I wouldn't worry about formatting until it's near completion, either.


I think people's styles differ here. I've spent time upfront on TDPL's 
page design and then I've enjoyed seeing parts of the finished product 
growing as I worked on it.

Andrei
Jun 16 2013
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, June 16, 2013 09:53:55 Walter Bright wrote:

 On 6/15/2013 3:19 PM, Jonathan M Davis wrote:

 For the book that I'm working on, I'm really not going to worry about the
 title at this point. I'm just going to write it, and I'll worry about
 stuff
 like the title and who might publish it or anything along those lines once
 it's much closer to completion.


 
 +1
 
 Also, I wouldn't worry about formatting until it's near completion, either.


I tend to worry about things like how paragraphs are separated and which words 
get emphasized as I go along (the same sorts of things that I'd worry about in 
a simple forum post), but I'm not going to worry about minute formatting 
details like mdash or ndash or anything like that. And I won't worry about the 
font style or page layout or anything along those lines until much later. 
Without having a bunch of text, I don't know how you'd be able to sort that 
out very well anyway, since you wouldn't be able to see what your tweaks did. 
But I _am_ doing enough formatting to care about whether I need $(P ) or not - 
just not a whole lot beyond that.

- Jonathan M Davis
Jun 16 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/16/2013 1:36 PM, Jonathan M Davis wrote:

 I tend to worry about things like how paragraphs are separated and which words
 get emphasized as I go along (the same sorts of things that I'd worry about in
 a simple forum post), but I'm not going to worry about minute formatting
 details like mdash or ndash or anything like that. And I won't worry about the
 font style or page layout or anything along those lines until much later.
 Without having a bunch of text, I don't know how you'd be able to sort that
 out very well anyway, since you wouldn't be able to see what your tweaks did.
 But I _am_ doing enough formatting to care about whether I need $(P ) or not -
 just not a whole lot beyond that.


Sure, whatever works best for you! Me, I'm definitely the kind of person who
can 
only think about one thing at a time, and when I'm writing text, I just let it 
flow in one uninterrupted stream.

Interestingly enough, most of the grammatical errors in my text come about 
because of editing it later.
Jun 16 2013
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Saturday, 15 June 2013 at 08:07:23 UTC, SomeDude wrote:

 On Saturday, 15 June 2013 at 03:56:50 UTC, Walter Bright wrote:

 Heck, to throw something out there, why not "D Best Practices"?


 Or "D Patterns and Practices" ?


+1
Jun 15 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/15/13 5:43 AM, Szymon Gatner wrote:

 Btw: Not sure if "effective" series isn't somehow propertiary and linked
 to Herb Sutter. I know he is not only responsible for c++ but also for



The "Effective" series at AWL is directed by Scott Meyers and would not 
preclude one from using the title elsewhere. That being said, I 
mentioned the book last night to Scott and he said if the author wants 
to publish it in that series, he'd be glad to look into it.

Andrei
Jun 14 2013
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 06/14/2013 07:17 PM, Jonathan M Davis wrote:


 It'll probably be the first book ever to be written entirely in ddoc.


The first ddoc book was a D book as well: ;)

 
http://code.google.com/p/ddili/source/browse/trunk/src/ders/d.en/foreach_opapply.d

Ali
Jun 15 2013
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, June 15, 2013 00:26:55 Ali =C3=87ehreli wrote:

 On 06/14/2013 07:17 PM, Jonathan M Davis wrote:
  > It'll probably be the first book ever to be written entirely in dd=


oc.

=20
 The first ddoc book was a D book as well: ;)
=20
=20
 http://code.google.com/p/ddili/source/browse/trunk/src/ders/d.en/fore=


ach_opa

 pply.d


So, you wrote your book with ddoc? I didn't know that. That's cool. It'=
s a lot=20
more versatile than you'd initially think.

- Jonathan M Davis
Jun 15 2013
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, June 15, 2013 08:55:11 H. S. Teoh wrote:

 I'm curious about how you manage to factor out / abstract away the
 niggling details of LaTeX, like the use of ".\ " after an abbreviation
 (to make it produce only an inter-word space, as opposed to the extra
 space at the end of a sentence), m-dash vs. n-dash, etc., some of which
 are quite specific to LaTeX but are quite necessary if you're going for
 print-quality typesetting. And what about embedded \footnote's? Section
 references? Do you have macros for all of them? Does it make it a bit
 cumbersome to type?


I'm early enough in the process that I haven't done much with those yet, and 
I'm likely to have to go back and fix that sort of thing up later (especially 
since about all I've done with LaTeX previously is write papers for college, 
and I didn't necessarily have to get everything as nice and exact as you would 
for a published book, so I'd likely be screwing some of that up even if I were 
writing directly in LaTeX). I expect to be using macros for them, but since 
you have to mark them up when writing in LaTeX anyway, it's not like I lose 
much using ddoc instead. It's just that the syntax changed. But it may be that 
if some of those can be automated, I'll end up doing something in the build 
script to manipulate the text to add that markup for me rather than using 
macros directly. I'll worry about that level of typesetting later. I wouldn't 
be worrying about that now even if I were writing directly in LaTeX.

And ddoc macros will easily allow me to add it all later. It's just that the 
ddoc files for stuff like html and epub will ignore them. I don't really need
to 
create something which is completely target-agnostic. I just need to create 
something that easily converts to all of the target formats that I need. And 
ddoc will do that just fine.


 I do have to process the ddoc before giving it to the compiler in
 order to generate the table of contents and index macros (since you
 can't generate those with just macros), but since I'm using a D script
 to do the build, that was actually pretty easy.


 
 [...]
 
 Isn't \tableofcontents enough to auto-generate the table of contents? Or
 are you talking about doing that for HTML output?


LaTeX will autogenerate the table of contents and the index, but html won't 
(and I don't think that something like epub will either, but I haven't gotten 
around to generating that yet). So, I have to generate the whole thing as 
macros, which the latex.ddoc file mostly gets rid of, and the html.ddoc file 
replaces with the appopriate text and links.

- Jonathan M Davis
Jun 15 2013
parent reply "matovitch" <camille.brugel laposte.net> writes:
I am referring to the beginning of this thread, but definitly 
wating for such a book to come out I have open a SO question 
(interactive media for a yet evolving langage) about effective 
design patterns and best practice in D. So if you have some 
clever methods you want to share, I am waiting for your answers. 
:-)
Jun 15 2013
parent reply "matovitch" <camille.brugel laposte.net> writes:
On Saturday, 15 June 2013 at 19:52:45 UTC, matovitch wrote:

 I am referring to the beginning of this thread, but definitly 
 wating for such a book to come out I have open a SO question 
 (interactive media for a yet evolving langage) about effective 
 design patterns and best practice in D. So if you have some 
 clever methods you want to share, I am waiting for your 
 answers. :-)


the link : http://stackoverflow.com/questions/tagged/d (forget 
the obvious)
Jun 15 2013
parent "matovitch" <camille.brugel laposte.net> writes:
the 'true' link : 
http://stackoverflow.com/questions/17127251/effective-d-best-practices-and-design-patterns
Jun 15 2013