www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Implementing interfaces using alias this

reply Balagopal Komarath <baluks gmail.com> writes:
Why doesn't this work? The Test!Duck type has a void quack() 
method but the compiler says it is not implemented.

import std.stdio;

interface IDuck
{
     void quack();
}

class Test(T) : IDuck
{
     T data;
     alias data this;
}

struct Duck
{
     void quack()
     {
         writeln("Quack");
     }
}


void main()
{
	Test!Duck d;
}
Jun 14
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Balagopal Komarath wrote:

 Why doesn't this work? The Test!Duck type has a void quack() method but 
 the compiler says it is not implemented.
'cause `alias this` is *not* a tool that can be used to emulate inheritance. no, `quack` is NOT impemented. `alias this` won't automagically paste the code.
Jun 14
next sibling parent reply Balagopal Komarath <baluks gmail.com> writes:
On Wednesday, 14 June 2017 at 09:41:49 UTC, ketmar wrote:
 Balagopal Komarath wrote:

 Why doesn't this work? The Test!Duck type has a void quack() 
 method but the compiler says it is not implemented.
'cause `alias this` is *not* a tool that can be used to emulate inheritance. no, `quack` is NOT impemented. `alias this` won't automagically paste the code.
Thanks for the reply. Is there any reason for disallowing this? AFAIK, the alias this guarantees that the interface provided by Test!T is a superset of the interface provided by T. And, when T = Duck, T provides everything required by IDuck. Couldn't the compiler check while instantiating that Test!Duck provides all methods required by IDuck?
Jun 14
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
Balagopal Komarath wrote:

 On Wednesday, 14 June 2017 at 09:41:49 UTC, ketmar wrote:
 Balagopal Komarath wrote:

 Why doesn't this work? The Test!Duck type has a void quack() method but 
 the compiler says it is not implemented.
'cause `alias this` is *not* a tool that can be used to emulate inheritance. no, `quack` is NOT impemented. `alias this` won't automagically paste the code.
Thanks for the reply. Is there any reason for disallowing this? AFAIK, the alias this guarantees that the interface provided by Test!T is a superset of the interface provided by T. And, when T = Duck, T provides everything required by IDuck. Couldn't the compiler check while instantiating that Test!Duck provides all methods required by IDuck?
besides improper using of `alias this`, there is a technical reason too: `struct` is not a `class`, it doesn't have VMT, and other class goodies. as i said, `alias this` is not a macro, it doesn't paste code, it just tells the compiler to make "symbol redirection" on typechecking. interfaces *require* a full-featured class, with VMT, and some hidden pointers to support hidden interface machinery.
Jun 14
parent reply Balagopal Komarath <baluks gmail.com> writes:
On Wednesday, 14 June 2017 at 11:40:02 UTC, ketmar wrote:
 interfaces *require* a full-featured class, with VMT, and some 
 hidden pointers to support hidden interface machinery.
I don't think that is the problem here. The type Test!Duck is a class and that type is the one implementing the interface.
Jun 14
parent ketmar <ketmar ketmar.no-ip.org> writes:
Balagopal Komarath wrote:

 On Wednesday, 14 June 2017 at 11:40:02 UTC, ketmar wrote:
 interfaces *require* a full-featured class, with VMT, and some hidden 
 pointers to support hidden interface machinery.
I don't think that is the problem here. The type Test!Duck is a class and that type is the one implementing the interface.
*sighs*
Jun 14
prev sibling parent reply Mike B Johnson <Mikey Ikes.com> writes:
On Wednesday, 14 June 2017 at 09:41:49 UTC, ketmar wrote:
 Balagopal Komarath wrote:

 Why doesn't this work? The Test!Duck type has a void quack() 
 method but the compiler says it is not implemented.
'cause `alias this` is *not* a tool that can be used to emulate inheritance. no, `quack` is NOT impemented. `alias this` won't automagically paste the code.
I don't think it has to do with pasting code. d.Quack() is well defined through the alias. Inheritance requires that a Quack() exists, and it does, through the alias. The compiler could easily create an implementation wrapper that uses the alias this. I believe it is simply because the logic is not implement in the compiler, not because there is some logic issue in it. import std.stdio; interface IDuck { void quack(); } class Test(T) : IDuck { T data; alias data this; void quack() { data.quack(); } } struct Duck { void quack() { writeln("Quack"); } } void main() { Test!Duck d; d.quack(); } which, unfortunately causes a segmentation fault ;)(from dpaste) (even if you remove IDuck) https://dpaste.dzfl.pl/69ddb3f2b1e9 The main issue is that the compiler would have to parse the alias and see if it has members that are to be used, not hard... but this is probably not standard behavior and might lead to other problems down the road(specially with multiple alias this). Basically, which quack to call? I think it's better to require it to be explicit(as I have tried to do).
Jun 14
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
Mike B Johnson wrote:

 I don't think it has to do with pasting code.

 d.Quack() is well defined through the alias. Inheritance requires that a 
 Quack() exists, and it does, through the alias.

 The compiler could easily create an implementation wrapper that uses the 
 alias this.
this is called "code pasting".
Jun 14
prev sibling parent Balagopal Komarath <baluks gmail.com> writes:
On Wednesday, 14 June 2017 at 12:35:05 UTC, Mike B Johnson wrote:
 void main()
 {
 	Test!Duck d;
 	d.quack();
 }

 which, unfortunately causes a segmentation fault ;)
I think that is because you are not initializing d using new Test!Duck();
Jun 14
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 6/14/17 5:34 AM, Balagopal Komarath wrote:
 Why doesn't this work? The Test!Duck type has a void quack() method but
 the compiler says it is not implemented.

 import std.stdio;

 interface IDuck
 {
     void quack();
 }

 class Test(T) : IDuck
 {
     T data;
     alias data this;
 }

 struct Duck
 {
     void quack()
     {
         writeln("Quack");
     }
 }


 void main()
 {
     Test!Duck d;
 }
An alias never causes implementation to be emitted. It should just be a forward from one symbol name to another. You need an actual function that can go into the vtable that takes a 'Test!Duck' as the context pointer. This wrapper has to be written by you. -Steve
Jun 14
prev sibling next sibling parent reply basile b. <b2.temp gmx.com> writes:
On Wednesday, 14 June 2017 at 09:34:27 UTC, Balagopal Komarath 
wrote:
 Why doesn't this work? The Test!Duck type has a void quack() 
 method but the compiler says it is not implemented.

 import std.stdio;

 interface IDuck
 {
     void quack();
 }

 class Test(T) : IDuck
 {
     T data;
     alias data this;
 }

 struct Duck
 {
     void quack()
     {
         writeln("Quack");
     }
 }


 void main()
 {
 	Test!Duck d;
 }
The way to do that in D is with mixins: interface IDuck { void quack(); } class Test(alias MyImpl) : IDuck { mixin MyImpl; } mixin template DuckImpl() { void quack() { import std.stdio; writeln("Quack Quack"); } } void main() { (new Test!DuckImpl).quack; }
Jun 14
parent reply Balagopal Komarath <baluks gmail.com> writes:
On Wednesday, 14 June 2017 at 21:04:55 UTC, basile b. wrote:
 The way to do that in D is with mixins:
That is an interesting solution. However, my original goal was to figure out whether one can make struct types behave polymorphically (Which is not mentioned in my original question). I know that this is not supported by design. I want to keep the original struct types but also allow functions to accept those struct types and do runtime dispatch. The following code should give a better idea by what I mean by this. https://dpaste.dzfl.pl/051f6a4da059 The user need only define Duck1, Duck2 ... with appropriate functions and mixin toDuck. Then a function that accepts a Duck can accept DuckLike (for dynamic dispatch) or templatize on the type of Duck.
Jun 14
parent basile b. <b2.temp gmx.com> writes:
On Wednesday, 14 June 2017 at 22:29:08 UTC, Balagopal Komarath 
wrote:
 On Wednesday, 14 June 2017 at 21:04:55 UTC, basile b. wrote:
 The way to do that in D is with mixins:
That is an interesting solution. However, my original goal was to figure out whether one can make struct types behave polymorphically (Which is not mentioned in my original question). I know that this is not supported by design. I want to keep the original struct types but also allow functions to accept those struct types and do runtime dispatch. The following code should give a better idea by what I mean by this. https://dpaste.dzfl.pl/051f6a4da059 The user need only define Duck1, Duck2 ... with appropriate functions and mixin toDuck. Then a function that accepts a Duck can accept DuckLike (for dynamic dispatch) or templatize on the type of Duck.
Duck typing doesn't work with the pattern you used initially. The pattern you used initially is much more similar to the solution i exposed. The point is that "alias" cant do what you wished. It's not in the language, end of story. Finally duck types in D are more like this: enum looksLikeaDuck(T) = __traits(hasMember, T, "quack"); class Test(T) if (looksLikeaDuck!T) { T data; alias data this; } struct Duck { void quack() { import std.stdio; writeln("Quack"); } } void main() { Test!Duck d; } you use traits to verify that the template parameter looks like a duck. It's not like in Swift where an aggregate is used. In D we use traits (even if traits can be used to verify that a template parameter is compliant with the member of an aggregate).
Jun 14
prev sibling next sibling parent reply Biotronic <simen.kjaras gmail.com> writes:
On Wednesday, 14 June 2017 at 09:34:27 UTC, Balagopal Komarath 
wrote:
 void main()
 {
 	Test!Duck d;
 }
As has been pointed out at length by others here, it's simply not how alias this is intended to work. I do see some arguments in favor of working that way, but I'm not sure what's the right solution. Anyways, there is another solution - we could write a template that does the conversion for us. There is std.typecons.Proxy, which seems like a good fit, however it doesn't work quite the way we want. Here however, is a solution that works for simple examples. It might work for more complex examples as well, but I simply haven't tested that: template duckImpl(alias a, TI, Fns...) { static if (Fns.length > 0) { mixin duckImpl!(a, TI, Fns[1..$]); alias thisFn = Fns[0]; enum string fnName = __traits(identifier, thisFn); mixin("ReturnType!thisFn "~fnName~"(Parameters!thisFn args) { return a."~fnName~"(args); }"); } } template duck(TI) if (is(TI == interface)) { TI duck(T)(T t) { import std.meta; import std.traits; template Functions(string s) { alias Functions = MemberFunctionsTuple!(TI, s); } static class Result : TI { private T payload; this(T value) { payload = value; } mixin duckImpl!(payload, TI, staticMap!(Functions, __traits(allMembers, TI))); } return new Result(t); } } interface I { void bar(); } struct S { void bar() { import std.stdio; writeln("OHAI"); } } unittest { I i = S().duck!I; i.bar(); } -- Biotronic
Jun 15
parent Balagopal Komarath <baluks gmail.com> writes:
On Thursday, 15 June 2017 at 07:12:56 UTC, Biotronic wrote:
 Here however, is a solution that works for simple examples.
This is awesome. Very generic. Thanks.
Jun 15
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 14 June 2017 at 09:34:27 UTC, Balagopal Komarath 
wrote:
 Why doesn't this work? The Test!Duck type has a void quack() 
 method but the compiler says it is not implemented.
You question was answered, but you can do this: ------------------ interface IDuck { void quack(); } struct Duck { void quack() { import std.stdio : writeln; writeln("Quack"); } } void main() { Duck d; import std.experimental.typecons : wrap; IDuck i = wrap!IDuck(d); i.quack(); } ----------------- Please note that you can't wrap to an interface which returns itself interface IDuck { IDuck clone(); } It fails because the struct would return a Duck and wouldn't wrap it to an IDuck. This is only a limitation on wrap because I haven't written the detection and appropriate wrapping function call.
Jun 15
parent reply Biotronic <simen.kjaras gmail.com> writes:
On Thursday, 15 June 2017 at 18:49:58 UTC, Jesse Phillips wrote:
 wrap!IDuck
Ah, so it does exist in Phobos. I thought it should be there, but didn't find it. Thanks! -- Biotronic
Jun 16
parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 16 June 2017 at 08:34:21 UTC, Biotronic wrote:
 On Thursday, 15 June 2017 at 18:49:58 UTC, Jesse Phillips wrote:
 wrap!IDuck
Ah, so it does exist in Phobos. I thought it should be there, but didn't find it. Thanks! -- Biotronic
Yeah, when Andrei introduced the wrap function I was disappointed it only wrapped classes. But in truth I haven't really been using it for structs either. That may partly be because it can't wrap to the range interface.
Jun 16