My experience with D's interfaces thus far is that they're useless for all but the simplest of designs.  Since D doesn't support multiple inheritance like C++, it's interface support MUST improve significantly if it is to be used for enterprise-class projects.

The issues I've bumped into so far (or heard others complain about) are:

-Covariance.  I've been told that this simply cannot work with the current D compiler implementation, and given a technical reason that I don't really understand, but I don't buy it.  We've got some pretty smart guys here, and I'm pretty confident that it could work.  (in other news, if anyone could point me at some resources to help me understand the mechanisms involved in "preventing" this from working, I'd appreciate it.  I don't really have any footing to stand on if I don't understand the issue.)  This one is a really big issue.  Try designing a good containers library with interfaces without support for this.  Not possible.

-Interface arrays.  Casting from Interface arrays to Object arrays doesn't work.  This issue I understand, and wouldn't consider it to be a bug.  That being said, it IS an issue that there is no easy way to do an operation like this, short of iterating through the entire array, and running the cast on each object before inserting it into a new array. This has bit me a few times

-Interfaces as AA keys.  This doesn't seem to work at all.  I dunno why.

-Interfaces are not implicitly castable to objects.  All interfaces instances are Objects, so this should work!

These are just the points I could come up with off the top 'o my head. Anybody else got any complaints?

There was another thread concerning interfaces about a week ago started by xs0, but it didn't go very far.  Are people not using interfaces?  Is that because we've just accepted that they're nearly useless?

D's interface support MUST improve if D wants to be a real OO language, and advance past a more convenient C.  As xs0 said, using interfaces should be transparent.  I agree.  Is anyone else willing to make a racket on this issue?

-John Demme

The lastest post in d.D.dtl says something about them too.

John Demme wrote:
> My experience with D's interfaces thus far is that they're useless for
> all but the simplest of designs.  Since D doesn't support multiple
> inheritance like C++, it's interface support MUST improve significantly
> if it is to be used for enterprise-class projects.
> 
> The issues I've bumped into so far (or heard others complain about) are:
> 
> -Covariance.  I've been told that this simply cannot work with the
> current D compiler implementation, and given a technical reason that I
> don't really understand, but I don't buy it.  We've got some pretty
> smart guys here, and I'm pretty confident that it could work.  (in other
> news, if anyone could point me at some resources to help me understand
> the mechanisms involved in "preventing" this from working, I'd
> appreciate it.  I don't really have any footing to stand on if I don't
> understand the issue.)  This one is a really big issue.  Try designing a
> good containers library with interfaces without support for this.  Not
> possible.
> 
> -Interface arrays.  Casting from Interface arrays to Object arrays
> doesn't work.  This issue I understand, and wouldn't consider it to be a
> bug.  That being said, it IS an issue that there is no easy way to do an
> operation like this, short of iterating through the entire array, and
> running the cast on each object before inserting it into a new array.
> This has bit me a few times
> 
> -Interfaces as AA keys.  This doesn't seem to work at all.  I dunno why.
> 
> -Interfaces are not implicitly castable to objects.  All interfaces
> instances are Objects, so this should work!
> 
> These are just the points I could come up with off the top 'o my head.
> Anybody else got any complaints?
> 
> There was another thread concerning interfaces about a week ago started
> by xs0, but it didn't go very far.  Are people not using interfaces?  Is
> that because we've just accepted that they're nearly useless?
> 
> D's interface support MUST improve if D wants to be a real OO language,
> and advance past a more convenient C.  As xs0 said, using interfaces
> should be transparent.  I agree.  Is anyone else willing to make a
> racket on this issue?
> 
> -John Demme
> 

It would help me, and likely anyone else who hasn't had much experience using interfaces in another language or in D to see some example problems and their ideal solution using interfaces.

I would suggest anyone with a problem with D's interfaces, post the problem you encountered in a thread entitled "Interface Support: <name>" where 'name' can be what we will use to identify that particular problem.

Then anyone who wants to can attempt to solve the problem using the current capabilities of D.

I believe this will clearly show where and why D is deficient, if indeed it is.

Regan

On Mon, 30 May 2005 14:40:47 -0400, John Demme <me@teqdruid.com> wrote:

> My experience with D's interfaces thus far is that they're useless for
> all but the simplest of designs.  Since D doesn't support multiple
> inheritance like C++, it's interface support MUST improve significantly
> if it is to be used for enterprise-class projects.
>
> The issues I've bumped into so far (or heard others complain about) are:
>
> -Covariance.  I've been told that this simply cannot work with the
> current D compiler implementation, and given a technical reason that I
> don't really understand, but I don't buy it.  We've got some pretty
> smart guys here, and I'm pretty confident that it could work.  (in other
> news, if anyone could point me at some resources to help me understand
> the mechanisms involved in "preventing" this from working, I'd
> appreciate it.  I don't really have any footing to stand on if I don't
> understand the issue.)  This one is a really big issue.  Try designing a
> good containers library with interfaces without support for this.  Not
> possible.
>
> -Interface arrays.  Casting from Interface arrays to Object arrays
> doesn't work.  This issue I understand, and wouldn't consider it to be a
> bug.  That being said, it IS an issue that there is no easy way to do an
> operation like this, short of iterating through the entire array, and
> running the cast on each object before inserting it into a new array.
> This has bit me a few times
>
> -Interfaces as AA keys.  This doesn't seem to work at all.  I dunno why.
>
> -Interfaces are not implicitly castable to objects.  All interfaces
> instances are Objects, so this should work!
>
> These are just the points I could come up with off the top 'o my head.
> Anybody else got any complaints?
>
> There was another thread concerning interfaces about a week ago started
> by xs0, but it didn't go very far.  Are people not using interfaces?  Is
> that because we've just accepted that they're nearly useless?
>
> D's interface support MUST improve if D wants to be a real OO language,
> and advance past a more convenient C.  As xs0 said, using interfaces
> should be transparent.  I agree.  Is anyone else willing to make a
> racket on this issue?
>
> -John Demme
>

"John Demme" <me@teqdruid.com> wrote in message news:1117478447.19815.73.camel@localhost.localdomain...
> -Covariance.  I've been told that this simply cannot work with the current D compiler implementation, and given a technical reason that I don't really understand, but I don't buy it.  We've got some pretty smart guys here, and I'm pretty confident that it could work.  (in other news, if anyone could point me at some resources to help me understand the mechanisms involved in "preventing" this from working, I'd appreciate it.  I don't really have any footing to stand on if I don't understand the issue.)  This one is a really big issue.  Try designing a good containers library with interfaces without support for this.  Not possible.

Covariance can mean different things. Exactly what meaning are you using - please provide an example.

> -Interface arrays.  Casting from Interface arrays to Object arrays doesn't work.  This issue I understand, and wouldn't consider it to be a bug.  That being said, it IS an issue that there is no easy way to do an operation like this, short of iterating through the entire array, and running the cast on each object before inserting it into a new array. This has bit me a few times
>
> -Interfaces as AA keys.  This doesn't seem to work at all.  I dunno why.

To work in an AA, it needs to be sortable and hashable. How would interfaces be sorted?

> -Interfaces are not implicitly castable to objects.  All interfaces instances are Objects, so this should work!

Implicit casting is a powerful tool, but if the language allows too many implicit casts, then things just start becoming unglued. Where the line is, I don't know. But to add this implicit cast to interfaces, I need a strong argument.

Walter wrote:
> To work in an AA, it needs to be sortable and hashable. How would interfaces
> be sorted?

Why is sortability required for a hashed AA?

Walter wrote:
> "John Demme" <me@teqdruid.com> wrote in message
> news:1117478447.19815.73.camel@localhost.localdomain...
> 
>>-Covariance.  I've been told that this simply cannot work with the
>>current D compiler implementation, and given a technical reason that I
>>don't really understand, but I don't buy it.  We've got some pretty
>>smart guys here, and I'm pretty confident that it could work.  (in other
>>news, if anyone could point me at some resources to help me understand
>>the mechanisms involved in "preventing" this from working, I'd
>>appreciate it.  I don't really have any footing to stand on if I don't
>>understand the issue.)  This one is a really big issue.  Try designing a
>>good containers library with interfaces without support for this.  Not
>>possible.
> 
> Covariance can mean different things. Exactly what meaning are you using -
> please provide an example.

At first glance it would appear that the OP's talking about one or other of these bugs:

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1726
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/3287

What other meanings did you have in mind?

<snip>
>>-Interfaces as AA keys.  This doesn't seem to work at all.  I dunno why.
> 
> To work in an AA, it needs to be sortable and hashable. How would interfaces
> be sorted?
<snip>

Aside from the same old question, no doubt somebody has written an interface and documented ordering semantics for it.  If not in D, then in Java or something.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

>> -Covariance.  I've been told that this simply cannot work with the current D compiler implementation, and given a technical reason that I don't really understand, but I don't buy it.  We've got some pretty smart guys here, and I'm pretty confident that it could work.  (in other news, if anyone could point me at some resources to help me understand the mechanisms involved in "preventing" this from working, I'd appreciate it.  I don't really have any footing to stand on if I don't understand the issue.)  This one is a really big issue.  Try designing a good containers library with interfaces without support for this.  Not possible.
>
>Covariance can mean different things. Exactly what meaning are you using - please provide an example.

Can it? I thought it would be just the opposit of contravariance.

e.g.

class Base {
Base foo () {...}
}

class Derived : Base {
Derived foo () {...}  // covariant return type
}



class Base2 {
void foo (Derived derived) {...}
}

class Derived2 : Base2 {
void foo (Base base) {...}  // contravariant argument type (currently not
supported)
}

These are the main usages of variant typing I know from other languages.

In article <d7i5m7$276i$1@digitaldaemon.com>, Stewart Gordon says...
>
[snip]
>
>Aside from the same old question, no doubt somebody has written an interface and documented ordering semantics for it.  If not in D, then in Java or something.

It's funny you mention Java.  Doesn't it have/mandate the "IComparable" interface for collections?  Seems that particular design move solves more problems than meets the eye.

- EricAnderton at yahoo

Matthias Becker wrote:
<snip>
>>Covariance can mean different things. Exactly what meaning are you using -
>>please provide an example.
> 
> Can it? I thought it would be just the opposit of contravariance.

But how many meanings does contravariance have?

<snip>
> class Derived2 : Base2 {
> void foo (Base base) {...}  // contravariant argument type (currently not
> supported)
> }
<snip>

So that's what this is called!  Do you know of a language that supports this?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

pragma wrote:
> In article <d7i5m7$276i$1@digitaldaemon.com>, Stewart Gordon says...
> 
> [snip]
> 
>>Aside from the same old question, no doubt somebody has written an interface and documented ordering semantics for it.  If not in D, then in Java or something.
> 
> It's funny you mention Java.  Doesn't it have/mandate the "IComparable"
> interface for collections?  Seems that particular design move solves more
> problems than meets the eye.

It has a Comparable interface.  This merely stipulates the presence of an ordering, and nothing about what the ordering should mean.

OTOH, the specification of an interface may mandate implementation of opEquals and/or opCmp to have certain semantics.  For example, look at the specs of Java's List and Set interfaces.

And only a handful of Java's collections require their elements to be Comparable.  TreeMap, TreeSet, any others?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.