View mode: basic / threaded / horizontal-split · Log in · Help
April 17, 2012
template+alias as an object's "namespace"
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?
April 17, 2012
Re: template+alias as an object's "namespace"
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 { ... }
April 18, 2012
Re: template+alias as an object's "namespace"
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.
April 18, 2012
Re: template+alias as an object's "namespace"
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.
April 18, 2012
Re: template+alias as an object's "namespace"
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.
April 18, 2012
Re: template+alias as an object's "namespace"
"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();
April 18, 2012
Re: template+alias as an object's "namespace"
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.
April 19, 2012
Re: template+alias as an object's "namespace"
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.
April 19, 2012
Re: template+alias as an object's "namespace"
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 :)
April 19, 2012
Re: template+alias as an object's "namespace"
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.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home