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 think this is a nice trick, but DDOC would need to support it for it be useful for API discovery.

On Thursday, 3 December 2015 at 20:59:59 UTC, 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. 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

At work we started using abstract final classes a lot for this. #notashamed

On 12/3/15 3:51 PM, 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'm going to take a step back and ask, what's wrong with stableFun?

-Steve

On 12/03/2015 05:46 PM, Steven Schveighoffer wrote:
> On 12/3/15 3:51 PM, 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'm going to take a step back and ask, what's wrong with stableFun?

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

On 12/3/15 5:54 PM, Andrei Alexandrescu wrote:
> On 12/03/2015 05:46 PM, Steven Schveighoffer wrote:
>> On 12/3/15 3:51 PM, 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'm going to take a step back and ask, what's wrong with stableFun?
>
> 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

alias stableLinearXxx = linearStableXxx;

-Steve

On Thursday, 3 December 2015 at 22:27:45 UTC, Andrei Alexandrescu wrote:
> 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?

Sorry, but I clearly didn't pay enough attention to what you were doing, because I only saw the namespace that you put at the module level and not the one inside of the struct. The one at the module level works just fine with a struct or class, avoids having to declare a alias, and allows you to just shove the documentation on the functions normally without having to explain that the functions in _MyNamespace need to be called with MyNamespace instead. It would also work inside of a class or struct except that based on the implementation of fun, you want access to the an object of the struct or class that it's in, and I don't see a way to do that anymore than you do.

That being said, I confess that I don't see any reason to create namespaces inside of a struct or class. They already have to be used as part of the struct or class, so they're namespaced at that level already, and if you have so many member functions that you feel the need to namespace them further, then that implies that you have way too many IMHO. But you can always just put the "namespace" in their names. It's even one character shorter, because you avoid the period.

- Jonathan M Davis

On Thursday, 3 December 2015 at 22:54:53 UTC, Andrei Alexandrescu wrote:
> On 12/03/2015 05:46 PM, Steven Schveighoffer wrote:
>> On 12/3/15 3:51 PM, 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'm going to take a step back and ask, what's wrong with stableFun?
>
> 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

That seems like it would be confusing, since it's non-obvious that those two things would be the same thing, though there also isn't an obvious hierarchy between linear and stable. AFAIK, they're orthogonal, so it's not obvious which would go inside the other. However, it also doesn't seem very user friendly to have that much extra stuff involved in what is essentially the function name. Whether it's using pseudo-namespaces or is just one long name, linearStableXXX / linear.stable.xxx and stableLinearXXX / stable.linear.xxx are both rather unwieldy, though I confess that I prefer not having the periods. It's shorter that way, and you don't have to explain the pseudo-namespaces to anyone that way either, since that's not exactly a normal idiom. But it would be best IMHO if we could find a way to either not need those extra tags on the function names or to at least minimze their length.

- Jonathan M Davis

On Thursday, 3 December 2015 at 22:44:35 UTC, deadalnix wrote:
> At work we started using abstract final classes a lot for this.

which works just fine normally, but apparently, Andrei wants to namespace member functions within a class or struct, which means having access to a specific object of that class or struct, and as far as I can tell, there's no way to do that with a nested class or struct.

- Jonathan M Davis

On Thursday, 3 December 2015 at 22:44:35 UTC, deadalnix wrote:
>
> At work we started using abstract final classes a lot for this. #notashamed

I used abstract final classes as well:  https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/stm32f42/gpio.d.

My use case is quite different, but it was the best method I could find for what I wanted to achieve.  I actually would have preferred to use modules for my use case, but I couldn't get around the one-module-per-file limitation.  That limitation seems rather arbitrary, so it may help with "namespacing" to remove that limitation.

Mike

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

Walter doesn't like it but there's always this option as well. IMO it's the cleanest way:

extern(C++, stable.linear)
{
	extern(D):
	
	enum sort = 0;
}

extern(C++, linear.stable)
{
	extern(D):
	
	alias sort = .stable.linear.sort;
}

void main()
{
	assert(stable.linear.sort == 0);
	assert(linear.stable.sort == 0);
}