template+alias as an object's "namespace"

[F i L]

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

Hakuna matata ;)


> It is a parameterized scope that is analysed upon instantiation.

Yes, but my request is to have an un-parameter-atized syntax 
which is sugar for a template with zero parameters and is useful 
for sub-scoping objects. See below for a more detailed argument.


> 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)

Not really. Reasons is I actually want _unsafe to be part of 
allMembers, but I also want to use it in a syntactically 
appealing way. Also, by separating the template from the object, 
you're (conceptually) breaking OOP design, unless _unsafe is 
designed as a reusable packet of code (ie, used by more than just 
Foo, like UFCS), which isn't the goal I intended. Here's another 
example:

     class Fighter : Ship
     {
       template visual {
         VisualMesh mesh;

         void update() { /* use visual.mesh */ }
         void updateAfter() { /* ditto */ }
       }

       template physic {
         CollisionMesh mesh;

         void udpate() { /* use physic.mesh */ }
       }

       void update() {
         visual.mesh.doSomething();
         physic.mesh.doSomething();
       }
     }

Now we have three functions "update", and two fields "mesh", 
without any conflicts because they're separated by scope. The 
classic way to do this is simply to prefix the names: visualMesh, 
visualUpdate, physicMesh, etc... but scoping fits with OOP 
design, and allows each sub-scope to use each variable without 
prefixing, eg, "visual.update()" doesn't need to prefix "visual." 
when using "visual.mesh".

I know that this can be today, though alternative ways. However, 
this requires very little prior knowledge of D's idioms to 
understand. Meaning non-D programmers will understand this at a 
glance. It makes sense, and code is where it should be, saving us 
all a little bit of head-ache.


What may also be prudent, is to have parameterless mixin 
templates, something like:

     struct Person
     {
       mixin intros = template {
         void sayHi() { ... }
         void sayAge() { ... }
       }

       void sayHi() {
         intros.sayHi();
         intros.sayAge();
       }
     }

     void main() {
       auto philip = Person();

       philip.sayHi();
       philip.sayAge();
       philip.intros.sayHi();
     }

The problem with always using mixin templates is that sometime 
you want to require the scope prefix, like in the Ship example 
above.


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

Agreed, though I don't see that as a reason to not *eventually* 
introduce a more usable syntax. If I had more time to dick around 
with DMD's internals, I'd make a pull request myself. I'm 
learning it, but it'll be awhile before I'll be trying to push 
code.


> Well, it can do it already.

Yes it can, but just even simple realiasing a template (or 
separating it out like your examples) requires a deeper 
understanding of D than what's graspable from my simple Ship 
example above. The easier to grasp, the more passing developer it 
will impress.


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

I don't think it needs too, though. We could have both.