I vaguely remembered I saw something like this a while ago:

http://dpaste.dzfl.pl/f11894a098c6

The trick could be more fluent, but it might have merit. Has anyone explored it? Is it a viable candidate for becoming a D idiom?

I was looking at this in conjunction with choosing a naming convention for container functions. Some functions are "stable" so that would be part of their name, e.g. insertStable or stableInsert. With this, it's possible to write lst.stable.insert.


Andrei

On Thursday, 3 December 2015 at 20:51:02 UTC, Andrei Alexandrescu wrote:
> I vaguely remembered I saw something like this a while ago:
>
> http://dpaste.dzfl.pl/f11894a098c6
>
> The trick could be more fluent, but it might have merit. Has anyone explored it? Is it a viable candidate for becoming a D idiom?
>
> I was looking at this in conjunction with choosing a naming convention for container functions. Some functions are "stable" so that would be part of their name, e.g. insertStable or stableInsert. With this, it's possible to write lst.stable.insert.
>
>
> Andrei

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. There is something wrong with the module system if one needs to resort to idioms like this.

My old finding about how it can be done on importing side : http://forum.dlang.org/post/pmezncogehwjnvjrxwns@forum.dlang.org

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.

On Thursday, 3 December 2015 at 20:51:02 UTC, Andrei Alexandrescu wrote:
> I vaguely remembered I saw something like this a while ago:
>
> http://dpaste.dzfl.pl/f11894a098c6
>
> The trick could be more fluent, but it might have merit. Has anyone explored it? Is it a viable candidate for becoming a D idiom?
>
> I was looking at this in conjunction with choosing a naming convention for container functions. Some functions are "stable" so that would be part of their name, e.g. insertStable or stableInsert. With this, it's possible to write lst.stable.insert.
>
>
> Andrei

I don't understand how it is namespace (it's just named scope for me) and why do we need template for that? Probably struct with static members would work the same without need for instantiating the template.

When talking about namespaces in the C++ sense, the feature of namespace is that it can be scattered among many files and can be 'using'.

On 12/03/2015 04:05 PM, FreeSlave wrote:
> I don't understand how it is namespace (it's just named scope for me)
> and why do we need template for that? Probably struct with static
> members would work the same without need for instantiating the template.

How would one use a struct for the List example? There's no access to "this". Yes, it's a named scope.

> When talking about namespaces in the C++ sense, the feature of namespace
> is that it can be scattered among many files and can be 'using'.

Wasn't thinking of C++ namespaces specifically, just an interesting artifact.

FWIW I wanted to use it to allow lst.linear.stable.insert() and lst.stable.linear.insert() to refer to the same function, but this is not working. Qualifies as a bug?

template _pseudo_namespace()
{
    void fun(int x)
    {
         import std.stdio;
         writeln(x);
    }
}
alias pseudo_namespace = _pseudo_namespace!();

struct List(T)
{
    template _stable()
    {
        void insert(int x)
        {
             import std.stdio;
             writeln(x);
        }
    }
    alias stable = _stable!();
    template _linear()
    {
        alias stable = _stable!();
    }
    alias linear = _linear!();
}

void main()
{
    pseudo_namespace.fun(1);
    List!int lst;
    lst._stable!().insert(2);
    lst.stable.insert(2);
    lst._linear!().stable.insert(2);
    lst.linear.stable.insert(2);
}


Andrei

On Thu, 03 Dec 2015 21:02:07 +0000, 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.

Usually the right answer, but then you get into circular dependency problems sometimes. You can fix circular dependency issues with deferred initialization, but that can muck up your API. You can fix them by moving static initialization into its own module, but that requires people to import the static initialization module.

So maybe explicit namespaces within a module are justified sometimes.

On Thursday, 3 December 2015 at 21:29:51 UTC, Andrei Alexandrescu wrote:
> On 12/03/2015 04:05 PM, FreeSlave wrote:
>> I don't understand how it is namespace (it's just named scope for me)
>> and why do we need template for that? Probably struct with static
>> members would work the same without need for instantiating the template.
>
> How would one use a struct for the List example? There's no access to "this". Yes, it's a named scope.

You declare static functions on a struct or class and then make the struct or class unusable as an object (e.g. by having a final abstract class or explicitly disabling all ways to construct the struct or class). There are at least a couple of places in Phobos that do that already (e.g. std.windows.registry.Registry and std.datetime.Clock both use final classes with an @disabled default constructor).

- Jonathan M Davis

On Thursday, 3 December 2015 at 21:46:03 UTC, Chris Wright wrote:
> So maybe explicit namespaces within a module are justified sometimes.

I definitely think that there are times when it's justified, but I also think that they should be used sparingly. I think that the only time that I've used them is when conceptually I have a global object that I'm calling functions on but don't actually have an object - e.g. std.datetime.Clock has functions that get the time from the system clock, but the system clock is not an actual object, and std.windows.registry.Registry groups some windows registry-stuff in single, conceptual object. Though while conceptually I like having stuff like Clock.currTime, given that the monotonic clock stuff is separated into core.time with pretty much only the realtime clock stuff being in std.datetime, it doesn't work very well to have a single place to query the clock like that. So, much as I like it, having std.datetime.Clock was probably a mistake.

Certainly, the only time that it makes sense to use a special namespace like this is when it makes sense to force the user to use the namespace every time they use the symbols in it rather than letting the module system differentiate things normally and let the user decide what they want to do. And there usually isn't a good reason to do that.

- Jonathan M Davis

On 12/03/2015 05:14 PM, Jonathan M Davis wrote:
> You declare static functions on a struct or class and then make the
> struct or class unusable as an object (e.g. by having a final abstract
> class or explicitly disabling all ways to construct the struct or class).

I must be dense. Consider:

struct List
{
    int x;
    template _stable()
    {
        void fun()
        {
             import std.stdio;
             writeln(this.x);
        }
    }
    alias stable = _stable!();
}

void main()
{
    List lst;
    lst.stable.fun();
}

Could you please redo the example with a struct?


Thanks,

Andrei

On Thursday, 3 December 2015 at 22:14:56 UTC, Jonathan M Davis wrote:
> On Thursday, 3 December 2015 at 21:29:51 UTC, Andrei Alexandrescu wrote:
>> On 12/03/2015 04:05 PM, FreeSlave wrote:
>>> [...]
>>
>> How would one use a struct for the List example? There's no access to "this". Yes, it's a named scope.
>
> You declare static functions on a struct or class and then make the struct or class unusable as an object (e.g. by having a final abstract class or explicitly disabling all ways to construct the struct or class). There are at least a couple of places in Phobos that do that already (e.g. std.windows.registry.Registry and std.datetime.Clock both use final classes with an @disabled default constructor).
>
> - Jonathan M Davis

Why would you need to resort to such hackery, when Andrei's solution is much more cleaner?