www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Interface Support: Return Types

reply Derek Parnell <derek psych.ward> writes:
My experience with Interfaces is zero, except for dabbling with the D
offering. My understanding of what interfaces are is that they are a
mechanism for defining a set of methods that must be implemented by a
class. About 30 minutes ago I was reading the DSource forum in which
'teqdruid' posted an simple example that shocked me into realizing that
there is at least one deficiency in the current Interface syntax.

Given the interfaces ...

 interface MutableList
 {
   MutableList opSlice(int a, int b);
 }

 interface Reproduce
 {
   Reproduce dup();
 }

and then a class based on this interface ...

 class MyList : MutableList, Reproduce
 {
   MutableList opSlice(int a, int b)
   {
      . . .
   }
   Reproduce dup()
   {
      . . .
   }
   . . . 
 }

This means that the MyList class must implement the interfaces' methods,
namely it must define a function called opSlice() that returns a
'MutableList', and function called dup() that must return a 'Reproduce'.
However, I would rather have it return a MyList class
instead, because as it now stands, to use such a class I must code ...

    MyList a = new MyList(xx);
    MyList b;
    MyList c;

    b = cast(MyList)a[2 .. 3];
    c = cast(MyList)a.dup;

The way I see it, an Interface is a generic way of defining a mandatory set
of member functions. The problem is that when defining the Interface, one
cannot know ahead of time which classes are going to be based on it, and
thus you cannot specify the required return type for functions defined in
the interface that return an instance of the class being defined.

If we could define interfaces thus (or similar syntax) ...

 interface MutableList
 {
   this opSlice(int a, int b);
 }
 interface Reproduce
 {
   this dup();
 }

then you can code the class definition as ...

 class MyList : MutableList, Reproduce
 {
   MyList opSlice(int a, int b)
   {
      . . .
   }
   MyList dup()
   {
      . . .
   }   
   . . . 
 }

and the compiler can make the appropriate substitution of 'MyList' for
'this' in the interface definition and still enforce strict type-safety.
Then I can do away with the redundant' cast' phrases when using the class,
thus making the code more readable and cleaner. And of course, making the
Interfaces a lot more generic in that they can be used to build any class
definition as required by the class designers.

By the way, the use of returning 'Object' in the interfaces still means you
need casts plus you lose strict type-safety.
-- 
Derek
Melbourne, Australia
31/05/2005 10:04:57 AM

-- 
Derek
Melbourne, Australia
31/05/2005 10:34:32 AM
May 30 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <bjopczpwluat$.z1g5tgrbc43m$.dlg 40tude.net>, Derek Parnell says...
My experience with Interfaces is zero, except for dabbling with the D
offering. My understanding of what interfaces are is that they are a
mechanism for defining a set of methods that must be implemented by a
class. About 30 minutes ago I was reading the DSource forum in which
'teqdruid' posted an simple example that shocked me into realizing that
there is at least one deficiency in the current Interface syntax.

Sounds like you want interfaces to support covariant return types. I wasn't aware that they didn't, so I agree. Sean
May 30 2005
parent Derek Parnell <derek psych.ward> writes:
On Tue, 31 May 2005 01:19:16 +0000 (UTC), Sean Kelly wrote:

 In article <bjopczpwluat$.z1g5tgrbc43m$.dlg 40tude.net>, Derek Parnell says...
My experience with Interfaces is zero, except for dabbling with the D
offering. My understanding of what interfaces are is that they are a
mechanism for defining a set of methods that must be implemented by a
class. About 30 minutes ago I was reading the DSource forum in which
'teqdruid' posted an simple example that shocked me into realizing that
there is at least one deficiency in the current Interface syntax.

Sounds like you want interfaces to support covariant return types. I wasn't aware that they didn't, so I agree.

As I say, I have no real experience with Interfaces, so if 'covariant return types' is the official jargonese for the concept then so be it ;-) I tried to describe the effect in common parlance used within the D language. I just googled the term and got a good description of it from http://c2.com/cgi/wiki?CovariantReturnTypes -- Derek Melbourne, Australia 31/05/2005 11:23:47 AM
May 30 2005
prev sibling next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Derek Parnell wrote:

 This means that the MyList class must implement the interfaces' methods,
 namely it must define a function called opSlice() that returns a
 'MutableList', and function called dup() that must return a 'Reproduce'.
 However, I would rather have it return a MyList class
 instead, because as it now stands, to use such a class I must code ...

But then doesn't that defeat the purpose of using the interface in the first place? Interfaces should be used when a standard interface is needed. It's a promise to the client that no matter what the underlying implementation, you are guaranteed that these methods will exist and that they will return these types. So imagine this feature you describe is implemented, and I write my code to rely on the fact that the MutableList being returned is actually a MyList. What happens if the underlying implementation changes and returns a SomeoneElsesList instead? I can't cast a MyList to a SomeoneElsesList, so my code is now broken. In general, when programming with interfaces, you should always program *to* the interface. That guarantees that your code will not break if the underlying implementation changes. D's casting mechanism makes it simple enough to handle specific implementations conditionally so that you can do this if you get a MyList, that for SomoneElsesList, and something else for any other MutableList. Allowing an interface implementation to break its interface's contract by varying return types just isn't a good thing, IMO.
May 30 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 31 May 2005 10:29:17 +0900, Mike Parker wrote:

 Derek Parnell wrote:
 
 This means that the MyList class must implement the interfaces' methods,
 namely it must define a function called opSlice() that returns a
 'MutableList', and function called dup() that must return a 'Reproduce'.
 However, I would rather have it return a MyList class
 instead, because as it now stands, to use such a class I must code ...

But then doesn't that defeat the purpose of using the interface in the first place?

I'm new at this so please bear with me.
Interfaces should be used when a standard interface is 
 needed. 

Yep, that makes sense.
It's a promise to the client that no matter what the underlying 
 implementation, you are guaranteed that these methods will exist and 
 that they will return these types.

Can I reword this to help me clarify your statement? It's a promise to the code that uses the class, which was defined based on the interface ('the client'), that no matter how the class actually implements the routines named in the interface ('the underlying implementation'), that these routines ('methods') will exist and that they will return the types specified by the interface definition. Yep, that's how I see it too.
 So imagine this feature you describe is implemented, and I write my code 
 to rely on the fact that the MutableList being returned is actually a 
 MyList. What happens if the underlying implementation changes and 
 returns a SomeoneElsesList instead? I can't cast a MyList to a 
 SomeoneElsesList, so my code is now broken.

Are you suggesting a scenario in which the MyList class changes the implementation of its 'opSlice' to return a SomeoneElsesList instead of a MyList class? In my proposed syntax, doing that would cause a compiler error because the Interface would have been defined to say that 'opSlice' must return an instance of the class that is based upon the interface. And as that would be MyList then returning a SomeoneElsesList would be against that Interface's requirements. The problem as I see it is that the current syntax mans that you must 'hard code' the return types in the interface definition. When there are sometimes that you wish it could be defined in terms of a 'symbolic' type rather than a real type. The 'symbolic' type would be resolved at compile time when the class using the interfaces is being defined.
 In general, when programming with interfaces, you should always program 
 *to* the interface. That guarantees that your code will not break if the 
 underlying implementation changes. 

Yes, but when a coder is looking at the documentation of a class, let's say a MyList, and sees that opSlice returns something other than the class itself, it is counter-intuitive. It would be like char[] a; char[] b; b = a[1..3]; failing because the slice operation does not return a char[]. Although it may be documented, it is not obvious. "And what is a 'MutableList' anyways?", the coder exclaims ;-)
 D's casting mechanism makes it simple 
 enough to handle specific implementations conditionally so that you can 
 do this if you get a MyList, that for SomoneElsesList, and something 
 else for any other MutableList.

In my view, the cast concept is a way to work around the type-safeness of the language. It is a hack. Unfortunately one which we are forced to use far to often for no good reason.
 Allowing an interface implementation to break its interface's contract 
 by varying return types just isn't a good thing, IMO.

Agreed. But that is not exactly what I'm saying. I'm not saying its okay for a class to return an 'int' when the interface says it should return a 'real'. I am saying, it would be useful to be able to specify an interface in such a way that the return type is resolved at the point in time that the class using the interface is defined, rather than at the time the interface is defined. It is analogous to templates, mixins or the dreaded macro, in that the actual code compiled is deferred. -- Derek Melbourne, Australia 31/05/2005 11:31:55 AM
May 30 2005
next sibling parent kris <fu bar.org> writes:
If I may add something:

An interface is a type of broker between two other parties; nothing 
more. If both parties respect the contract implied by the broker, then 
something akin to magic can happen ~ otherwise, all bets are off.

As a broker, the Interface must absolve itself from all implementation 
details. That typically includes concrete types of any kind. Lets call 
such an animal a "pure" interface. Non-pure interfaces are feasible for 
many things, but you should really ask if an abstract class is a better 
approach for such instances.

Then there's the "multiple inheritance replacement" thing: it would be 
convenient to support covariant return types within Interfaces for 
non-pure usage of this nature, but D does not do this ~ it sticks to the 
pure implementation instead.

You can emulate covariant return types through inherited interface 
returns instead ~ but it can be a pain, for a number of reasons.



Derek Parnell wrote:
 On Tue, 31 May 2005 10:29:17 +0900, Mike Parker wrote:
 
 
Derek Parnell wrote:


This means that the MyList class must implement the interfaces' methods,
namely it must define a function called opSlice() that returns a
'MutableList', and function called dup() that must return a 'Reproduce'.
However, I would rather have it return a MyList class
instead, because as it now stands, to use such a class I must code ...

But then doesn't that defeat the purpose of using the interface in the first place?

I'm new at this so please bear with me.
Interfaces should be used when a standard interface is 
needed. 

Yep, that makes sense.
It's a promise to the client that no matter what the underlying 
implementation, you are guaranteed that these methods will exist and 
that they will return these types.

Can I reword this to help me clarify your statement? It's a promise to the code that uses the class, which was defined based on the interface ('the client'), that no matter how the class actually implements the routines named in the interface ('the underlying implementation'), that these routines ('methods') will exist and that they will return the types specified by the interface definition. Yep, that's how I see it too.
So imagine this feature you describe is implemented, and I write my code 
to rely on the fact that the MutableList being returned is actually a 
MyList. What happens if the underlying implementation changes and 
returns a SomeoneElsesList instead? I can't cast a MyList to a 
SomeoneElsesList, so my code is now broken.

Are you suggesting a scenario in which the MyList class changes the implementation of its 'opSlice' to return a SomeoneElsesList instead of a MyList class? In my proposed syntax, doing that would cause a compiler error because the Interface would have been defined to say that 'opSlice' must return an instance of the class that is based upon the interface. And as that would be MyList then returning a SomeoneElsesList would be against that Interface's requirements. The problem as I see it is that the current syntax mans that you must 'hard code' the return types in the interface definition. When there are sometimes that you wish it could be defined in terms of a 'symbolic' type rather than a real type. The 'symbolic' type would be resolved at compile time when the class using the interfaces is being defined.
In general, when programming with interfaces, you should always program 
*to* the interface. That guarantees that your code will not break if the 
underlying implementation changes. 

Yes, but when a coder is looking at the documentation of a class, let's say a MyList, and sees that opSlice returns something other than the class itself, it is counter-intuitive. It would be like char[] a; char[] b; b = a[1..3]; failing because the slice operation does not return a char[]. Although it may be documented, it is not obvious. "And what is a 'MutableList' anyways?", the coder exclaims ;-)
D's casting mechanism makes it simple 
enough to handle specific implementations conditionally so that you can 
do this if you get a MyList, that for SomoneElsesList, and something 
else for any other MutableList.

In my view, the cast concept is a way to work around the type-safeness of the language. It is a hack. Unfortunately one which we are forced to use far to often for no good reason.
Allowing an interface implementation to break its interface's contract 
by varying return types just isn't a good thing, IMO.

Agreed. But that is not exactly what I'm saying. I'm not saying its okay for a class to return an 'int' when the interface says it should return a 'real'. I am saying, it would be useful to be able to specify an interface in such a way that the return type is resolved at the point in time that the class using the interface is defined, rather than at the time the interface is defined. It is analogous to templates, mixins or the dreaded macro, in that the actual code compiled is deferred.

May 30 2005
prev sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Derek Parnell wrote:
 On Tue, 31 May 2005 10:29:17 +0900, Mike Parker wrote:

 Are you suggesting a scenario in which the MyList class changes the
 implementation of its 'opSlice' to return a SomeoneElsesList instead of a
 MyList class? In my proposed syntax, doing that would cause a compiler
 error because the Interface would have been defined to say that 'opSlice'
 must return an instance of the class that is based upon the interface. And
 as that would be MyList then returning a SomeoneElsesList would be against
 that Interface's requirements.

And this is what I don't understand. Constidering that MutableList already dictates that opSlice must return a MutableList object, what is the befefit of allowing a MutableList implementation to narrow that scope from MutableList to MyList? The method in question should be able to return any instance of a MutableList implementation, because that's what the interface says it should return. If I'm calling that method from another class, I (generally) don't care if I'm getting what type of MutableList I'm getting.
 The problem as I see it is that the current syntax mans that you must 
 'hard code' the return types in the interface definition.

That's what an interface is for, isn't it? Call this method, and you will have this type returned.
 When there are sometimes that you wish it could be defined in terms 

 be resolved at compile time when the class using the interfaces is
 being defined.

This is the part I'm not getting.
 Yes, but when a coder is looking at the documentation of a class,
 let's say
 a MyList, and sees that opSlice returns something other than the class
 itself, it is counter-intuitive. It would be like

   char[] a;
   char[] b;

   b = a[1..3];

 failing because the slice operation does not return a char[]. 

'MutableList'
 anyways?", the coder exclaims  ;-)

Okay, this is why opSlice is a bad example. Operator overloads are already part of the language spec, and have no business being part of an interface definition in the first place (unless you want to enforce a specific behavior for special cases). interface Foo { void amethod(); } class Bar : Foo { void amethod() {} } class BarToo : Foo { void amethod() {} } interface Baz { Foo getFoo(); } class BazImpl : Baz { Foo getFoo(); } Baz says that everytime I call Foo, I will get a Foo. Maybe I'll get a Bar or a BarToo, but it will always be a Foo. They syntax you propose would allow this: class BazImplToo : Baz { Bar getFoo() {} } This means that BazImplToo no longer strictly adheres to the Baz interface, because it can't return any type of Foo, but only Foos which are instances of, or extended instances of, Bar. This is how I'm looking at it. What I'm no getting is what benefit this brings.
May 30 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 31 May 2005 12:50:51 +0900, Mike Parker wrote:

 Derek Parnell wrote:
 On Tue, 31 May 2005 10:29:17 +0900, Mike Parker wrote:

 Are you suggesting a scenario in which the MyList class changes the
 implementation of its 'opSlice' to return a SomeoneElsesList instead of a
 MyList class? In my proposed syntax, doing that would cause a compiler
 error because the Interface would have been defined to say that 'opSlice'
 must return an instance of the class that is based upon the interface. And
 as that would be MyList then returning a SomeoneElsesList would be against
 that Interface's requirements.

And this is what I don't understand. Constidering that MutableList already dictates that opSlice must return a MutableList object,

Stop there! What I'm proposing is that MutableList dictates that opSlice must return an instance of *whatever* class that is using MutableList as one of its building blocks. For instance: interface ML { this meth_one(int a, int b); } class BaseList { . . . } class ListOne: BaseList, ML { ListOne meth_one(int a, int b) { ListOne x = new ListOne; . . . return x; } } class ListTwo: ML { ListTwo meth_one(int a, int b) { ListTwo x = new ListTwo; . . . return x; } } By using the syntax "this funcname()" inside the interface definition, I'm trying to tell the compiler that the return type is not known yet and will only be known when this interface is used on a class definition, at which time the compiler will substitute the word 'this' with the name of the class being defined. The contract ('interface promise') is still being met. The only thing is that the specific return type is not known at the time the interface was designed. It allows much more generic interfaces to be designed. It says, "when using this interface to define a class, you must implement a member function that accepts these parameters are returns an instance of the class that you are defining."
 what is 
 the befefit of allowing a MutableList implementation to narrow that 
 scope from MutableList to MyList?

Narrow? How is it narrowing it? I would have thought I was expanding it. Are you thinking that I mean that when the class is being defined, that the interface is then 'locked' into RAM or such.
 The method in question should be able 
 to return any instance of a MutableList implementation, because that's 
 what the interface says it should return. 

Currently, yes. But what-if you could tell the compile to be more flexible.
If I'm calling that method 
 from another class, I (generally) don't care if I'm getting what type of 
 MutableList I'm getting.

Huh? There is only one type of MutableList. Are you saying that any class that uses MutableList as a basis becomes a type of MutableList? How does that work with multiple interfaces being used on a single class definition?
  > The problem as I see it is that the current syntax mans that you must 
  > 'hard code' the return types in the interface definition.
 
 That's what an interface is for, isn't it? Call this method, and you 
 will have this type returned.

Yes.
  > When there are sometimes that you wish it could be defined in terms 
 of > a 'symbolic' type rather than a real type. The 'symbolic' type would
  > be resolved at compile time when the class using the interfaces is
  > being defined.
 
 This is the part I'm not getting.

Hopefully I've described more fully now.
  > Yes, but when a coder is looking at the documentation of a class,
  > let's say
  > a MyList, and sees that opSlice returns something other than the class
  > itself, it is counter-intuitive. It would be like
 
  >   char[] a;
  >   char[] b;
 
  >   b = a[1..3];
  >
  > failing because the slice operation does not return a char[]. 
 Although > it may be documented, it is not obvious. "And what is a 
 'MutableList'
  > anyways?", the coder exclaims  ;-)
 
 Okay, this is why opSlice is a bad example. Operator overloads are 
 already part of the language spec, and have no business being part of an 
 interface definition in the first place (unless you want to enforce a 
 specific behavior for special cases).
 
 interface Foo
 {
     void amethod();
 }
 
 class Bar : Foo
 {
     void amethod() {}
 }
 
 class BarToo : Foo
 {
     void amethod() {}
 }
 
 interface Baz
 {
     Foo getFoo();
 }
 
 class BazImpl : Baz
 {
     Foo getFoo();
 }
 
 Baz says that everytime I call Foo, I will get a Foo. Maybe I'll get a 
 Bar or a BarToo, but it will always be a Foo.

This is the part that I'm not getting. Given that an interface is a list of methods that must be implemented, how can a function return an interface? Are you saying that the getFoo() function is returning a list of method signatures? Why would I want that? It seems that you are suggesting that an interfaces is really some sort of light-weight class. If the classes Bar and BarToo also implemented other methods and data,, but different from each other, what would getFoo() return? Is it just an object that allows you to call only the Foo methods implemented in both Bar and BarToo, but not access the other methods or data in them?
 They syntax you propose 
 would allow this:
 
 class BazImplToo : Baz
 {
     Bar getFoo() {}
 }

No, it will not. Because Baz says it must return a Foo, returning a Bar is wrong. And even if Baz said it can return a 'this thingy', your example would still be wrong because a Bar is not a BazImplToo.
 This means that BazImplToo no longer strictly adheres to the Baz 
 interface, because it can't return any type of Foo, but only Foos which 
 are instances of, or extended instances of, Bar. This is how I'm looking 
 at it. What I'm no getting is what benefit this brings.

I'll try another example: interface Foo { this amethod(); } interface Baz { this bmethod(); int cmethod(); } class Bar : Foo { Bar amethod() { . . .} private real x; } class BarToo : Foo, Baz { BarToo amethod() { . . .} BarToo bmethod() { . . .} int cmethod(){ . . . } } class BazImpl : Baz { BarImpl bmethod() { . . .} int cmethod(){ . . . } } -- Derek Melbourne, Australia 31/05/2005 1:55:36 PM
May 30 2005
parent reply kris <fu bar.org> writes:
Derek Parnell wrote:
<snip>
If I'm calling that method 
from another class, I (generally) don't care if I'm getting what type of 
MutableList I'm getting.

Huh? There is only one type of MutableList. Are you saying that any class that uses MutableList as a basis becomes a type of MutableList? How does that work with multiple interfaces being used on a single class definition?

Part of the power within Interfaces comes from their agnostic properties: if there is no concrete implementation referenced anywhere within, then /anybody/ can implement the interface and magically be compatible will all clients of said interface. That is; If IMutableList is an interface, each of you, John, and I can provide a completely independent implementation, yet all clients of IMutableList just don't care which one is "plugged in" at any given time. There are times when the client will want to know, but that's perhaps a different issue. You'll often find such things returned via the so-called Factory Pattern. This is why interfaces typically reference only other Interfaces (in return values and/or arguments), or define enums and other simple attributes. They were intended to be a pure abstraction of a contract. That doesn't mean some interesting mutations can't be proposed, but I think it's where some confusion can arise.
  
 
 The problem as I see it is that the current syntax mans that you must 
 'hard code' the return types in the interface definition.

That's what an interface is for, isn't it? Call this method, and you will have this type returned.


The traditional Interface would return another interface instead.
May 30 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 30 May 2005 21:55:16 -0700, kris wrote:

 Derek Parnell wrote:
 <snip>
If I'm calling that method 
from another class, I (generally) don't care if I'm getting what type of 
MutableList I'm getting.

Huh? There is only one type of MutableList. Are you saying that any class that uses MutableList as a basis becomes a type of MutableList? How does that work with multiple interfaces being used on a single class definition?


As I say, I *really* am new to all of this Interface stuff. The stuff you wrote below may as well been written in (digital?) Martian for the amount of it I know I really understood ;-)
 Part of the power within Interfaces comes from their agnostic 
 properties: 

'agnostic properties' = defines signatures (name, and return and input parameters) and doesn't care who or how they are implemented?
 if there is no concrete implementation 

'concrete implementation' = implementation code that is compilable?
 referenced anywhere within, 

Is this saying "if the code that defines an interface does not, itself, reference any actual implementation code"? What do you mean by 'reference'? Do you mean 'contains'? Or what???
then /anybody/ can implement the interface and magically be 
 compatible will all clients of said interface. That is; If IMutableList 
 is an interface, each of you, John, and I can provide a completely 
 independent implementation, yet all clients of IMutableList just don't 
 care which one is "plugged in" at any given time.

Is a "client of IMutableList" any class that inherits IMutable? And does this mean that given the code below ... interface iOne { double amethod(); } class Circle: iOne { double amethod() { return (radius * 2 * PI) / 360.00L ; } real bmethod() { ... } } class BattleTank: iOne { double amethod() { return RemainingAmmo / FireRate; } byte[] cmethod() { ... } } class HumanHeart: iOne { double amethod() { return Ventricle.Capacity + Atrium.Capacity; } long* dmethod() { ... } } that somehow the classes Circle, BattleTank and HumanHeart are related in so far as I can use them interchangeably at times? And what do you mean by "plugged in". Is this a runtime or a compile time operation?
 There are times when 
 the client will want to know, but that's perhaps a different issue. 

Has the meaning of "client" changed here? A what is it that the client might want to know?
 You'll often find such things returned via the so-called Factory Pattern.

What things? Interfaces? Class instances?
 This is why interfaces typically reference only other Interfaces (in 
 return values and/or arguments), or define enums and other simple 
 attributes. 

Are you saying that the methods defined in an interface definition typically only name other interfaces as data types in the return value and function arguments? Then can they specify functions that can be comnpiled? Surely, somewhere along the way a method in an interface must use real data types?
 They were intended to be a pure abstraction of a contract.

Yes, this is my understanding of them too. Nothing concrete. *JUST* a list of function signatures that is used by the compiler to ensure that classes that use the interface have all the interface's methods implemented. My assumption is that there is never any object code that is generated by an interface definition - it is just a device used by the compiler and not the linker.
 That doesn't mean some interesting mutations can't be proposed, but I 
 think it's where some confusion can arise.

Not really. I'm overly confused as it is ;-)
  
 
 The problem as I see it is that the current syntax mans that you must 
 'hard code' the return types in the interface definition.

That's what an interface is for, isn't it? Call this method, and you will have this type returned.


The traditional Interface would return another interface instead.

What is meant (i.e. Show me the code) by an interface *returning* another interface? How can something that is never instantiated execute any code to return anything? Or does this terminology ('return another interface') refer to some action by the compiler and not a run time action? -- Derek Melbourne, Australia 31/05/2005 2:57:28 PM
May 30 2005
parent reply kris <fu bar.org> writes:
Derek Parnell wrote:
 As I say, I *really* am new to all of this Interface stuff. The stuff you
 wrote below may as well been written in (digital?) Martian for the amount
 of it I know I really understood ;-)

Funny!
Part of the power within Interfaces comes from their agnostic 
properties: 

'agnostic properties' = defines signatures (name, and return and input parameters) and doesn't care who or how they are implemented?

Right. If I understand you correctly :)
if there is no concrete implementation 

'concrete implementation' = implementation code that is compilable?

Yeah; the actual implementation of an Interface is closely related to the implementation of abstract methods defined in a superclass ~ both are 'concrete' rather than 'abstract'. It is only said implementation that produces linkable code.
referenced anywhere within, 

Is this saying "if the code that defines an interface does not, itself, reference any actual implementation code"? What do you mean by 'reference'? Do you mean 'contains'? Or what???

Aye: "if the /declaration/ of an Interface does not ..." ~ there's no code in an Interface itself. By reference, I mean the Interface module does not import any module declaring a 'concrete', linkable, anything. It may very well import other Interfaces. Repeat ad nauseum <g>
then /anybody/ can implement the interface and magically be 
compatible will all clients of said interface. That is; If IMutableList 
is an interface, each of you, John, and I can provide a completely 
independent implementation, yet all clients of IMutableList just don't 
care which one is "plugged in" at any given time.

Is a "client of IMutableList" any class that inherits IMutable?

No. Or not really. The client of an Interface is usually a consumer/user of it, like someone buying something in a store. A class providing a concrete, linkable version of some Interface is said to "implement" the interface. If Walter were to define/declare an Interface describing a String class (*cough*), and you were to write an implementing class then I, as a consumer/user, could instantiate the interface via your concrete implementation. Further, John could write an alternate concrete implementation, and I could use that instead, without changing my 'client' code. That is, If I stick to using the Interface only, then I can switch between one or the other. For such simple usage, one could use an abstract base class instead. Since you mentioned the use of inheritance, it's worth noting that each Interface can inherit from others; multiple others if appropriate.
 And does this mean that given the code below ...
 
  interface iOne
  {
      double amethod();
  }
 
  class Circle: iOne
  {
      double amethod() { return (radius * 2 * PI) / 360.00L ; }
      real bmethod() { ... }
  }
 
  class BattleTank: iOne
  {
      double amethod() { return RemainingAmmo / FireRate; }
      byte[] cmethod() { ... }
  }
 
  class HumanHeart: iOne
  {
      double amethod() { return Ventricle.Capacity + Atrium.Capacity; }
      long* dmethod() { ... }
  }
  
 that somehow the classes Circle, BattleTank and HumanHeart are related in
 so far as I can use them interchangeably at times?

Yes. The Interface is just a contract ~ if various implementations attach completely different semantics to that Interface, that's a problem <g>. Oftentimes, an Interface is used as a means to discuss details of how two parties will collaborate ~ the mechanics are enforced by the Interface methods, but the semantics are agreed upon in other ways; usually heavily documented in the Interface module. An important point (I think) is this: an Interface is a means of /decoupling/ two independent entities, such that they no longer contain explicit ties to one another. Again, one can use an abstract base class for simple cases ~ Interfaces provide the extra 'decoupling' horsepower when needed, within a singly-rooted hierarchy.
 
 And what do you mean by "plugged in". Is this a runtime or a compile time
 operation?
 

It can be both ~ largely depends upon language capabilities. One key aspect of 'pluggable' systems is that a client should not know anything more than what the contract exposes. In other words, anything that /changes/ across different implementations should be abstracted via the Interface. The same is true for an abstract base-class. This is part and parcel of the decoupling aspect.
 
There are times when 
the client will want to know, but that's perhaps a different issue. 

Has the meaning of "client" changed here? A what is it that the client might want to know?

Some clients break the contract when they want to use specific capabilities of certain concrete implementations. They do this by casting the Interface to a known, concrete implementation, and using that instead. This is bogus, but it does happen. All decooupling efforts are thus borked. The resolution is to refactor the interface, or lay down some smack upon the client.
You'll often find such things returned via the so-called Factory Pattern.

What things? Interfaces? Class instances?

Factories return concrete class instances; but typically do so by returning an Interface. Specifically, a class instance that implements the appropriate interface: # // interface # interface IWibble # { # bool isWibbly(); # bool isWobbly(); # } # // concrete implementation # class Wibble : IWibble # { # bool isWibbly() {return true;} # bool isWobbly() {return false;} # } # // highly simplified factory # class WibbleFactory # { # static IWibble produce () # { # return new Wibble(); # } # } # // consumer # main() # { # IWibble wibbler = WibbleFactory.produce (); # if (wibbler.isWobbly()) # ... # } The factory is usually consider a producer in such cases; it hides how the Interface is implemented by encapsulating the concrete instance within itself. The client/consumer doesn't know, or care, from whence the implementation cometh from.
This is why interfaces typically reference only other Interfaces (in 
return values and/or arguments), or define enums and other simple 
attributes. 

Are you saying that the methods defined in an interface definition typically only name other interfaces as data types in the return value and function arguments?

Usually, yes. This makes them agnostic of any particular implementation. It's not a hard requirement, but it's necessary where "fully decoupled" is desirable.
 Then can they specify functions that can be comnpiled?
 Surely, somewhere along the way a method in an interface must use 

 types?

Traditional Interfaces are contract declarations only. No code is specified within them. That occurs within Concrete implementations of the Interface.
They were intended to be a pure abstraction of a contract.

Yes, this is my understanding of them too. Nothing concrete. *JUST* a list of function signatures that is used by the compiler to ensure that classes that use the interface have all the interface's methods implemented. My assumption is that there is never any object code that is generated by an interface definition - it is just a device used by the compiler and not the linker.

Aye. In D, I believe they are just like a list of delegate pointers.
That doesn't mean some interesting mutations can't be proposed, but I 
think it's where some confusion can arise.

Not really. I'm overly confused as it is ;-)
 


The problem as I see it is that the current syntax mans that you must 
'hard code' the return types in the interface definition.

That's what an interface is for, isn't it? Call this method, and you will have this type returned.


The traditional Interface would return another interface instead.

What is meant (i.e. Show me the code) by an interface *returning* another interface? How can something that is never instantiated execute any code to return anything? Or does this terminology ('return another interface') refer to some action by the compiler and not a run time action?

# interface ITransmission # { # .... # } # interface IVehicle # { # // Fully decoupled ~ uses Interfaces only # ITransmission getTranny (); # void setTranny (ITransmission tranny); # } # class MyBus : IVehicle # { # ITransmission tranny = new SuperDuperWhoopeeTranny(); # # ITransmission getTranny() # { # return tranny; # } # ... # } Note the declaration of IVehicle. It is independent of any concrete Transmission. As would be any client of IVehicle. Though I'm not sure what I'd do with a concrete transmission; or a concrete bus, for that matter :) BTW; these examples are somewhat trivialized, and don't even touch upon multiple Interface implementations or Interface inheritance. I'm sure you realize that.
May 31 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 31 May 2005 00:51:21 -0700, kris wrote:

[a whole lot of good things about Interfaces that I'm still digesting.]

Things are clearer now but I still need to get my head around this better. 

More research is required...

-- 
Derek Parnell
Melbourne, Australia
1/06/2005 2:03:31 AM
May 31 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"kris" <fu bar.org> wrote in message news:d7h4lh$12nu$1 digitaldaemon.com...
 Yes, this is my understanding of them too. Nothing concrete. *JUST* a


 of function signatures that is used by the compiler to ensure that


 that use the interface have all the interface's methods implemented. My
 assumption is that there is never any object code that is generated by


 interface definition - it is just a device used by the compiler and not


 linker.

Aye. In D, I believe they are just like a list of delegate pointers.

No, in D, an interface is a pointer to a vtbl[]. Each interface implemented by a class gets a vptr allocated in the class instance, and that vptr points to a vtbl[] for the functions that implement it. Casting a class to an interface means adding an offset to the 'this' pointer to point to the vptr member for that interface. Casting from an interface back to the class means subtracting that offset. The subtract is a little tricky since the pointer doesn't know where it came from, so the first entry in the interface's vtbl[] is an instance of the class Interface with the necessary offset. The cast is handled by the library function _d_interface_cast(). So, an interface "instantiation" is a physical pointer that can get copied, passed as a function argument, etc. The problem with interface covariance with classes is that that pointer is not the same as the 'this' pointer to a class. There are ways to deal with this, such as putting out special vtbl[]s with 'this' adjustor thunks in them, but D doesn't do that now and since it's a complex implementation problem, it won't for now. Covariance for class inheritance works because the 'this' for the base class is exactly the same as the 'this' for a derived class.
May 31 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <d7j9s9$fq8$1 digitaldaemon.com>, Walter says...
The problem with interface covariance with classes is that that pointer is
not the same as the 'this' pointer to a class. There are ways to deal with
this, such as putting out special vtbl[]s with 'this' adjustor thunks in
them, but D doesn't do that now and since it's a complex implementation
problem, it won't for now.

Sounds reasonable. I kind of see interface implementation as a contract anyway, so I'd accept the argument that return type is part of that contract. Sean
May 31 2005
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
in D, an interface is a pointer to a vtbl[]. Each interface implemented
by a class gets a vptr allocated in the class instance, and that vptr points
to a vtbl[] for the functions that implement it.

Such a vtbl[] coud be created at runtime as well, right? So perhaps there could be a new language-construct (I call it protocoll for now) which basically behaes like an interface, but doesn't need to be explicitly implemented: protocol Foo { void method (); } class Bar { void method () {...} } void function (Foo foo) {...} void main () { function (new Bar()); // OK } Protocolls might be a bit more expensive than interfaces as the vtbl[] has to be generated at runtime, but they are more flexible as well. E.g. you can write a protocol that has a subset of some classes you haven't written and this way allow to use these classes polymorphically in your own framework.
Jun 01 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <d7k1b0$15md$1 digitaldaemon.com>, Matthias Becker says...
in D, an interface is a pointer to a vtbl[]. Each interface implemented
by a class gets a vptr allocated in the class instance, and that vptr points
to a vtbl[] for the functions that implement it.

Such a vtbl[] coud be created at runtime as well, right? So perhaps there could be a new language-construct (I call it protocoll for now) which basically behaes like an interface, but doesn't need to be explicitly implemented: protocol Foo { void method (); } class Bar { void method () {...} } void function (Foo foo) {...} void main () { function (new Bar()); // OK } Protocolls might be a bit more expensive than interfaces as the vtbl[] has to be generated at runtime, but they are more flexible as well. E.g. you can write a protocol that has a subset of some classes you haven't written and this way allow to use these classes polymorphically in your own framework.

Cool idea, but this scares me a bit--it allows an object to impersonate something it was never intended to impersonate. What if Bar.method has a function that has nothing to do with what Foo.method is supposed to do? Sean
Jun 01 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
I guess you'll find
this idea is close to yours:
http://www.heron-language.com/interfaces.html
Chapter 'Unintrusive Retroactive Polymorphism'
The idea is just perfect, imho.

Andrew.


"Matthias Becker" <Matthias_member pathlink.com> wrote in message 
news:d7k1b0$15md$1 digitaldaemon.com...
in D, an interface is a pointer to a vtbl[]. Each interface implemented
by a class gets a vptr allocated in the class instance, and that vptr 
points
to a vtbl[] for the functions that implement it.

Such a vtbl[] coud be created at runtime as well, right? So perhaps there could be a new language-construct (I call it protocoll for now) which basically behaes like an interface, but doesn't need to be explicitly implemented: protocol Foo { void method (); } class Bar { void method () {...} } void function (Foo foo) {...} void main () { function (new Bar()); // OK } Protocolls might be a bit more expensive than interfaces as the vtbl[] has to be generated at runtime, but they are more flexible as well. E.g. you can write a protocol that has a subset of some classes you haven't written and this way allow to use these classes polymorphically in your own framework.

Jun 04 2005
next sibling parent Ben Hinkle <Ben_member pathlink.com> writes:
In article <d7t04k$5se$1 digitaldaemon.com>, Andrew Fedoniouk says...
I guess you'll find
this idea is close to yours:
http://www.heron-language.com/interfaces.html
Chapter 'Unintrusive Retroactive Polymorphism'
The idea is just perfect, imho.

Andrew.

I don't know much about Objective-C but I think it also has a concept roughly like that called "informal protocols" (a protocol in Objective-C is like an interface in D). It would be an interesting thought experiment to take the object model of Objective-C and graft it onto the non-object-model of D and presto Objective-D. Scary but fun to think about. :-)
"Matthias Becker" <Matthias_member pathlink.com> wrote in message 
news:d7k1b0$15md$1 digitaldaemon.com...
in D, an interface is a pointer to a vtbl[]. Each interface implemented
by a class gets a vptr allocated in the class instance, and that vptr 
points
to a vtbl[] for the functions that implement it.

Such a vtbl[] coud be created at runtime as well, right? So perhaps there could be a new language-construct (I call it protocoll for now) which basically behaes like an interface, but doesn't need to be explicitly implemented: protocol Foo { void method (); } class Bar { void method () {...} } void function (Foo foo) {...} void main () { function (new Bar()); // OK } Protocolls might be a bit more expensive than interfaces as the vtbl[] has to be generated at runtime, but they are more flexible as well. E.g. you can write a protocol that has a subset of some classes you haven't written and this way allow to use these classes polymorphically in your own framework.


Jun 04 2005
prev sibling parent "Kris" <fu bar.com> writes:
Christopher Diggins was around here for a little while:
http://www.digitalmars.com/d/archives/digitalmars/D/1097.html

I thought it was a good idea also.



"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d7t04k$5se$1 digitaldaemon.com...
 I guess you'll find
 this idea is close to yours:
 http://www.heron-language.com/interfaces.html
 Chapter 'Unintrusive Retroactive Polymorphism'
 The idea is just perfect, imho.

 Andrew.


 "Matthias Becker" <Matthias_member pathlink.com> wrote in message
 news:d7k1b0$15md$1 digitaldaemon.com...
in D, an interface is a pointer to a vtbl[]. Each interface implemented
by a class gets a vptr allocated in the class instance, and that vptr
points
to a vtbl[] for the functions that implement it.

Such a vtbl[] coud be created at runtime as well, right? So perhaps


 could
 be a new language-construct (I call it protocoll for now) which


 behaes
 like an interface, but doesn't need to be explicitly implemented:

 protocol Foo {
 void method ();
 }

 class Bar {
 void method () {...}
 }

 void function (Foo foo) {...}

 void main ()
 {
 function (new Bar());  // OK
 }

 Protocolls might be a bit more expensive than interfaces as the vtbl[]


 to be
 generated at runtime, but they are more flexible as well. E.g. you can
 write a
 protocol that has a subset of some classes you haven't written and this
 way
 allow to use these classes polymorphically in your own framework.


Jun 04 2005
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:bjopczpwluat$.z1g5tgrbc43m$.dlg 40tude.net...
 My experience with Interfaces is zero, except for dabbling with the D
 offering. My understanding of what interfaces are is that they are a
 mechanism for defining a set of methods that must be implemented by a
 class. About 30 minutes ago I was reading the DSource forum in which
 'teqdruid' posted an simple example that shocked me into realizing that
 there is at least one deficiency in the current Interface syntax.

That's very weird. I always assumed D's interfaces supported covariant return types, as inherited classes do, though I've not yet needed to use them, so I never knew it didn't work. Maybe it's just an oversight in the spec?
May 30 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:bjopczpwluat$.z1g5tgrbc43m$.dlg 40tude.net...
 If we could define interfaces thus (or similar syntax) ...

  interface MutableList
  {
    this opSlice(int a, int b);
  }
  interface Reproduce
  {
    this dup();
  }

 then you can code the class definition as ...

  class MyList : MutableList, Reproduce
  {
    MyList opSlice(int a, int b)
    {
       . . .
    }
    MyList dup()
    {
       . . .
    }
    . . .
  }

I can't help but think that an interface template will fit the bill here: interface MutableList(T) { T opSlice(int a, int b); } interface Reproduce(T) { T dup(); } class MyList : MutableList!(MyList), Reproduce!(MyList) { MyList opSlice(int a, int b) { . . . } MyList dup() { . . . } . . . }
May 31 2005
parent Derek Parnell <derek psych.ward> writes:
On Tue, 31 May 2005 20:07:32 -0700, Walter wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:bjopczpwluat$.z1g5tgrbc43m$.dlg 40tude.net...
 If we could define interfaces thus (or similar syntax) ...

  interface MutableList
  {
    this opSlice(int a, int b);
  }
  interface Reproduce
  {
    this dup();
  }

 then you can code the class definition as ...

  class MyList : MutableList, Reproduce
  {
    MyList opSlice(int a, int b)
    {
       . . .
    }
    MyList dup()
    {
       . . .
    }
    . . .
  }

I can't help but think that an interface template will fit the bill here:

I didn't know one could do that! I think I'll update the wiki DocComments about this. This is exactly what is required for my purposes (though the syntax is a tad bulky). -- Derek Melbourne, Australia 1/06/2005 1:16:59 PM
May 31 2005