template+alias as an object's "namespace"

[Timon Gehr]

On 04/19/2012 09:45 PM, F i L wrote:
> Timon Gehr wrote:
>>
>> struct Foo {
>>   struct Unsafe {
>>   static:
>>     string name;
>>     void bar() {
>>       writeln(name); // fine
>>     }
>>   }
>> }
>
> Foo.Unsafe.name is static and not per-instance. That's a completely
> different thing than having a "namespace" within the object which serves
> only as a semantic layer to classify property access.
>

Ah, I see what you are getting at. I failed to read your post carefully 
enough. Sorry about that.

>
>>> Like I said, it's completely possible with templates today, you just
>>> have to alias them for nice syntax. Parameterless templates
>>
>> It is not really a 'template' if it is parameterless and does not need
>> to be instantiated.
>
> Sure it is. Templates provide a semantic convenience over reusable bits
> of code that get resolved at CT. It's more like a CT struct than a CT
> function.

It is a parameterized scope that is analysed upon instantiation.

> So it makes perfect sense to have parameterless ones,
> especially because you can already have that, only with less pretty code.
>

This is an alternative:

private template _unsafe(){
     string name;
     void bar() {
         writeln(name);
     }
}
struct Foo{
     mixin _unsafe Unsafe;
}

Is this better? (_unsafe can be a local template of struct Foo, but then 
it invades the allMembers)

In fact, this pattern could be generalized to

template Classify(string s){mixin(s);}

struct Foo{
     mixin Classify!q{
         string name;
         void bar() {
             writeln(name);
         }
     } Unsafe;
}

With the alternate alias syntax, this would then probably work as well:


template Classify(string s){mixin(s);}

struct Foo{
     mixin Unsafe = Classify!q{
         string name;
         void bar() {
             writeln(name);
         }
     }
}


>
>>> would just
>>> be sugar, but that sugar would be nice when you want to use
>>> classifications like this in real code.
>>
>> This idiom imho shouldn't be overused. Renamed imports usually suffice.
>
> I don't see how import renaming applies to what I've suggested. It's a
> completely different topic.

It is similar, but here it does indeed not apply.

> I'm sure it could be abused, like anything
> else, but It is useful in some areas, and I don't see any reason not to
> have a usable syntax for something that's already achievable in D.
>

I think the current syntax hardly qualifies as unusable. I agree that it 
is not the prettiest/most specific one imaginable.

> Honestly I think this could be another "nah nah nah, look what our
> language can do" bullet point in D's favor.  So far as I know, no other
> (efficient) language can sub-classify it's objects without increasing
> their per-instance memory footprint + require manually wiring up the
> connection. While in D it's simply an emergent feature of a beautiful
> template design.
>

Well, it can do it already.

> D gives more control over the structure of objects than any other
> language, without sacrificing a thing. That sounds like a good marketing
> point to me :)

D's design sacrifices ease of implementation to some extent.