Would it be prudent to make Templates be able to be used without parameters? (Or something along those lines) Consider the following:

  struct Foo1 {
    string name = "Foo1";

    alias Unsafe!() unsafe;
    	
    template Unsafe() {
      string name = "Bar";

      void bar() {
        writeln(this.name, name);
      }
    }
  }

  struct Foo2 {
    string name = "Foo2";
    string unsafe_name = "Bar";

    void unsafe_bar() {
      writeln(name, unsafe_name);
    }
  }

  void main() {
    auto foo1 = Foo1();
    auto foo2 = Foo2();

    foo1.Unsafe!().bar(); // ugly
    foo1.unsafe.bar(); // nice
    foo2.unsafe_bar(); // classic
  }

The classic way works, or course, but it's not as pretty :)
I may be breaking some sacred rule of OOP here, but I think this kind of classification comes in handy. In fact, I think D's the only language that actually allows for this syntax without increasing an objects memory footprints.

It could be *useful* in situations where you want to simplistically wrap a complex system, say X11, and provide _a few_ convenience functions, while still providing complete access to X11 objects, but grouping them into logical subsection. Example:

  class Window {
    private XDisplay* _display;

    void create(...) { /* use _display; */ }
    void delete(...) { /* ditto */ }

    template X11 {
      @property auto display() { return _display; }
    }
  }

The only thing that erks me is the name "template" doesn't really match it's function at this point. Maybe something like "alias template" would make more sense:

  alias template X11 { ... }

idk. What are peoples thoughts on this? Good? Bad? Ugly?

Another possible syntax is, given the talked about:

  alias name = type;

syntax, we could just use that in combination with "anonymous templates":

  alias X11 = template {
    @property auto display() { return _display; }
  }

Though, now that I look at it I'm kinda just like parameterless templates:

  template X11 { ... }

I wanted this for a long time now. There were many situations when I needed just that, but I didn't want to invent dummy structures for that, because I didn't want any run-time change.

On Wed, Apr 18, 2012 at 3:04 AM, F i L <witte2008@gmail.com> wrote:
> Another possible syntax is, given the talked about:
>
>  alias name = type;
>
> syntax, we could just use that in combination with "anonymous templates":
>
>  alias X11 = template {
>
>    @property auto display() { return _display; }
>  }
>
> Though, now that I look at it I'm kinda just like parameterless templates:
>
>  template X11 { ... }
>



-- 
Bye,
Gor Gyolchanyan.

On Wednesday, 18 April 2012 at 10:04:07 UTC, Gor Gyolchanyan wrote:
> I wanted this for a long time now. There were many situations when I
> needed just that, but I didn't want to invent dummy structures for
> that, because I didn't want any run-time change.

Yes I agree, there's been many times where I wanted this kind of compositional ability... but It looks like you and I are the only ones interested in these sorts of aesthetics.

If you ask me, aesthetics is one of the most important parts of any
programming language.
Any programming language is an intermediate between human language and
machine language.
Quality code generation defines how good the language speaks in machine.
Convenient syntax defines how good the language speaks human.
In this respect, making the language prettier is just as important as
making the code it generates faster.

On Wed, Apr 18, 2012 at 8:12 PM, F i L <witte2008@gmail.com> wrote:
> On Wednesday, 18 April 2012 at 10:04:07 UTC, Gor Gyolchanyan wrote:
>>
>> I wanted this for a long time now. There were many situations when I needed just that, but I didn't want to invent dummy structures for that, because I didn't want any run-time change.
>
>
> Yes I agree, there's been many times where I wanted this kind of compositional ability... but It looks like you and I are the only ones interested in these sorts of aesthetics.
>
>



-- 
Bye,
Gor Gyolchanyan.

"F i L" <witte2008@gmail.com> wrote:
> Would it be prudent to make Templates be able to be used without parameters? (Or something along those lines) Consider the following:
> 
>   struct Foo1 {
>     string name = "Foo1";
> 
>     alias Unsafe!() unsafe;
> 
>     template Unsafe() {
>       string name = "Bar";
> 
>       void bar() {
>         writeln(this.name, name);
>       }
>     }
>   }
> 
>   struct Foo2 {
>     string name = "Foo2";
>     string unsafe_name = "Bar";
> 
>     void unsafe_bar() {
>       writeln(name, unsafe_name);
>     }
>   }
> 
>   void main() {
>     auto foo1 = Foo1();
>     auto foo2 = Foo2();
> 
>     foo1.Unsafe!().bar(); // ugly
>     foo1.unsafe.bar(); // nice
>     foo2.unsafe_bar(); // classic
>   }
> 
> The classic way works, or course, but it's not as pretty :)
> I may be breaking some sacred rule of OOP here, but I think this kind of
> classification comes in handy. In fact, I think D's the only language
> that actually allows for this syntax without increasing an objects memory footprints.
> 
> It could be *useful* in situations where you want to simplistically wrap a complex system, say X11, and provide _a few_ convenience functions, while still providing complete access to X11 objects, but grouping them into logical subsection. Example:
> 
>   class Window {
>     private XDisplay* _display;
> 
>     void create(...) { /* use _display; */ }
>     void delete(...) { /* ditto */ }
> 
>     template X11 {
>       @property auto display() { return _display; }
>     }
>   }
> 
> The only thing that erks me is the name "template" doesn't really match
> it's function at this point. Maybe something like "alias template" would make more sense:
> 
>   alias template X11 { ... }
> 
> idk. What are peoples thoughts on this? Good? Bad? Ugly?

struct Foo1 {
    struct Unsafe {
    static:
        void bar() { ... }
    }
}
Foo1 f;
f.Unsafe.bar();

kennytm wrote:
> struct Foo1 {
>     struct Unsafe {
>     static:
>         void bar() { ... }
>     }
> }
> Foo1 f;
> f.Unsafe.bar();

That fails when you add variables though:

  struct Foo {
    struct Unsafe {
      string name;
      static void bar() {
        writeln(name); // error: needs 'this'
      }
    }
  }

Like I said, it's completely possible with templates today, you just have to alias them for nice syntax. Parameterless templates would just be sugar, but that sugar would be nice when you want to use classifications like this in real code.

On 04/19/2012 01:41 AM, F i L wrote:
> kennytm wrote:
>> struct Foo1 {
>>     struct Unsafe {
>>     static:
>>         void bar() { ... }
>>     }
>> }
>> Foo1 f;
>> f.Unsafe.bar();
>
> That fails when you add variables though:
>
>    struct Foo {
>      struct Unsafe {
>        string name;
>        static void bar() {
>          writeln(name); // error: needs 'this'
>        }
>      }
>    }
>

struct Foo {
  struct Unsafe {
  static:
    string name;
    void bar() {
      writeln(name); // fine
    }
  }
}


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

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

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.


>> 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. So it makes perfect sense to have parameterless ones, especially because you can already have that, only with less pretty code.


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

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.

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

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.