the 'true' link : http://stackoverflow.com/questions/17127251/effective-d-best-practices-and-design-patterns

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");
    }
}

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.

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.

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

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

On Sunday, June 16, 2013 01:55:35 Dmitry Olshansky wrote:
> 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.

Cookbook is in a similar situation with Effective, if not worse, as O'Reilly has a whole line of programming books with that name, and AFAIK, every programming book with Cookbook in its name has been published though them. So, an author who wanted to use that title would probably have to publish specifically through O'Reilly to get it into that series.

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

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.

- Jonathan M Davis

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

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.

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.