On Friday, 4 December 2015 at 06:57:17 UTC, Walter Bright wrote:
> On 12/3/2015 12:59 PM, Dicebot wrote:
>> This isn't any different from namespace struct idiom, is it? I don't like it
>> because it forces the namespace usage even if it isn't needed.
>
> If you use mixin templates, you can use or not use the namespace. prefix.

True, that didn't come to my mind. But that pushes resulting coding style from "weird but tolerable" to "good luck explaining newbies why D modules are not broken". All for the sake of a putting a dot in the name. Look at perspective for a moment think if you would be happy to use a language which avdertises such approach as idiomatic (for one of most basic language operations).

On 12/4/2015 12:48 AM, Dicebot wrote:
> True, that didn't come to my mind. But that pushes resulting coding style from
> "weird but tolerable" to "good luck explaining newbies why D modules are not
> broken". All for the sake of a putting a dot in the name. Look at perspective
> for a moment think if you would be happy to use a language which avdertises such
> approach as idiomatic (for one of most basic language operations).

I don't understand your comment that modules are broken. With imports, you can use the module name as a prefix or not.

On Friday, 4 December 2015 at 09:30:08 UTC, Walter Bright wrote:
> I don't understand your comment that modules are broken. With imports, you can use the module name as a prefix or not.

I am referring to Andrei proposal for template "namespaces" + your explanation of how it can be flattened via mixin. It works but advocating such means as idiomatic when there is existing module system (with named imports and stuff) sends a bad message about quality and applicability of such module system - especially considering it will be one of first things newbies see.

On 12/04/2015 02:12 AM, Jacob Carlborg wrote:
> On 2015-12-03 22:02, Dicebot wrote:
>> And for that specific "stable" example - just make it a separate module,
>> problem solved. To make use of module system for symbol resolution one
>> needs to have many small modules, _that_ should become D idiom.
>
> I agree. I will just be difficult to convince the core developers of that.

How would one create a module inside a class or struct? -- Andrei

On 12/04/2015 02:19 AM, Minas Mina wrote:
> On Thursday, 3 December 2015 at 22:54:53 UTC, Andrei Alexandrescu wrote:
>> Nothing. But one thing I was keeping an eye for would be to allow
>> lst.stable.linear.xxx and lst.linear.stable.xxx with one body. -- Andrei
>
> Please don't. Choose one to be the outer and one to be the inner.
> Otherwise people will sometimes use one, sometimes the other and code
> will look inconsistent. Just choose one.

Sensible, dziękuję. -- Andrei

On 12/4/2015 1:35 AM, Dicebot wrote:
> On Friday, 4 December 2015 at 09:30:08 UTC, Walter Bright wrote:
>> I don't understand your comment that modules are broken. With imports, you can
>> use the module name as a prefix or not.
>
> I am referring to Andrei proposal for template "namespaces" + your explanation
> of how it can be flattened via mixin. It works but advocating such means as
> idiomatic when there is existing module system (with named imports and stuff)
> sends a bad message about quality and applicability of such module system -
> especially considering it will be one of first things newbies see.

I argued against pseudo-namespaces.

On 2015-12-04 15:00, Andrei Alexandrescu wrote:

> How would one create a module inside a class or struct? -- Andrei

Hmm, I see that I really didn't understand what you were trying to do. So you want to create a namespace inside a class or struct? I would probably create a separate struct and return that from a function

struct List(T)
{
    static struct Stable
    {
        void fun(int x) { }
    }
    auto stable() { return Stable(); }
}

List!(int) list;

list.stable.fun(2);

-- 
/Jacob Carlborg

Jacob Carlborg <doob@me.com> wrote:
> On 2015-12-04 15:00, Andrei Alexandrescu wrote:
> 
>> How would one create a module inside a class or struct? -- Andrei
> 
> Hmm, I see that I really didn't understand what you were trying to do. So you want to create a namespace inside a class or struct? I would probably create a separate struct and return that from a function
> 
> struct List(T)
> {
>     static struct Stable
>     {
>         void fun(int x) { }
>     }
>     auto stable() { return Stable(); }
> }
> 
> List!(int) list;
> 
> list.stable.fun(2);
> 

Won't work. Fun has no access to the list.

On Friday, 4 December 2015 at 09:30:08 UTC, Walter Bright wrote:
> On 12/4/2015 12:48 AM, Dicebot wrote:
>> True, that didn't come to my mind. But that pushes resulting coding style from
>> "weird but tolerable" to "good luck explaining newbies why D modules are not
>> broken". All for the sake of a putting a dot in the name. Look at perspective
>> for a moment think if you would be happy to use a language which avdertises such
>> approach as idiomatic (for one of most basic language operations).
>
> I don't understand your comment that modules are broken. With imports, you can use the module name as a prefix or not.

The problem with using modules at this point is, as I come to same
conclusion, that it forces name repetitions. Example I am defining
many APIs right now for database operations. File is over thousand
of lines, and each API is used for separate operations. I can create
a separate module for each API to decrease complexity, but than
both the name of module and name of API function are almost same
thing. And, as it is very clearly seen in Phobos as well, many
names are repeated again and again which creates ugly code. I even
cannot propose any solution to this other then following the long
way: using package.d to alias same function in both module and package
which feels hackish.

Andrei is, I guess, following that approach to prevent this as well.

On Friday, 4 December 2015 at 20:58:02 UTC, tcak wrote:
> On Friday, 4 December 2015 at 09:30:08 UTC, Walter Bright wrote:
>> On 12/4/2015 12:48 AM, Dicebot wrote:
>>> [...]
>>
>> I don't understand your comment that modules are broken. With imports, you can use the module name as a prefix or not.
>
> The problem with using modules at this point is, as I come to same
> conclusion, that it forces name repetitions. Example I am defining
> many APIs right now for database operations. File is over thousand
> of lines, and each API is used for separate operations. I can create
> a separate module for each API to decrease complexity, but than
> both the name of module and name of API function are almost same
> thing. And, as it is very clearly seen in Phobos as well, many
> names are repeated again and again which creates ugly code. I even
> cannot propose any solution to this other then following the long
> way: using package.d to alias same function in both module and package
> which feels hackish.
>
> Andrei is, I guess, following that approach to prevent this as well.

Another solution of mine was to allow giving same name to multiple
module files. So, compile would merge them as they are single. This
would very easily solve the most name repetition problems. (There is
a security risk here as overriding is possible, but I ignore it for now).