View mode: basic / threaded / horizontal-split · Log in · Help
April 19, 2012
Re: template+alias as an object's "namespace"
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 

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

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

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


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

> 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 

> 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.
May 14, 2013
Re: template+alias as an object's "namespace"
On Thursday, 19 April 2012 at 22:24:52 UTC, F i L wrote:
> snip

Sorry to dig this up again, but I'm looking for something to 
provide stubs for a compile time interface in a struct:

mixin template Stubs() {
    template __Stubs__() {
        void sayHi() { writeln("hi"); }
    alias __Stubs__!() this;

struct Foo {
    mixin Stubs;

void main() {

This is so that I am still able to override sayHi() at compile 
time with my own implementation in Foo.
I would love to do that, but it won't compile right now. If I 
alias to something else than this, it works though.
I could alias-this with an inner struct, i.e. when I change the 
template mixin to

mixin template Stubs() {
    struct __Stubs__ {
        void sayHi() { writeln("hi"); }
    private __Stubs__ __s;
    alias __s this;

But this means I have to sacrifice some bytes in Foo to store the 
super struct, noticable as you add fields to Foo. This is not too 
bad, but since we have templates and mixins and stuff, is there 
maybe a way I haven't thought about?
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home