interfaces :-(

[michal.minich at gmail.com]

This is now possible in D, here's example, hope it's helpful


interface Comparable (T)
{
void compareTo(T o);
}

class A : Comparable!(A)
{
char[] textA;

void compareTo(A o)
{
printf ("A.compareTo: " ~ o.textA ~\n);
printf ( \n );
}	
}

class B : A, Comparable!(B)
{
char[] textB;

void compareTo(B o)
{
printf ("B.compareTo: " ~ o.textA ~\n);
printf ("B.compareTo: " ~ o.textB ~\n);
printf ( \n );
}
}


void main ()
{
A a = new A();
B b = new B();

a.textA = "TextA in instance of A";

b.textA = "TextA in instance of B";
b.textB = "TextB in instance of B";

a.compareTo(a);
a.compareTo(b);
b.compareTo(b);
}

/* the output is:
A.compareTo: TextA in instance of A

A.compareTo: TextA in instance of B

B.compareTo: TextA in instance of B
B.compareTo: TextB in instance of B
*/


In article <e6rg4h$1a9v$1 at digitaldaemon.com>, sean.fritz at gmail.com says...
>
>In article <dqoho0$bmh$1 at digitaldaemon.com>,
>=?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= says...
>>
>>xs0 wrote:
>>
>>As far as I understand it, the current interfaces can only be used on
>>simple single inheritance structures and on closed source products that
>>want to hide the implementation from end users. At least I cannot come
>>up with any creative ways in using them.
>
>Well, FWIW I've been using invariant return type Java interfaces for years
>without realizing it was even a problem.  I don't use abstract classes on a
>regular basis, because I tend to practice inversion of control and other design
>patterns that promote the use of interfaces as the only name coupling between
>classes wherever possible.
>
>I don't really, at this time understand the need for covariant return types.  My
>first reaction to learning about them was to view them as needlessly complex,
>mostly useful in order to save one or two pointer lookups at method dispatch
>time in certain select situations.  They are nice in that they do allow for
>compile time type checking, which leads into my second reaction.
>
>My second reaction was that all of these issues should be solvable by
>parameterizing(is that the correct D term for putting a type parameter on an
>interface?) the interface  in a similar way to the way Comparable<T> is
>parameterized in Java.  That is if D allows for overloading based on return
>types (which I do not know the answer to).
>
>While implementing parameter covariance through Comparable<T> has some serious
>issues, most notably you can never write the following code, it is one possible
>solution to this problem.
>
>//example illegal code -- you can't implement the same interface with 
>//different type arguments in Java
>
>class A implements Comparable<A> {
>compareTo(A o) {
>..
>}
>}
>
>class B extends A implements Comparable<B> { //compile time error B cannot
>//implement Comparable<A> and
>//Comparable<B> simultaneously
>..
>}
>
>PS:  Sorry if these points have already been made.  I realize this is an old
>post.  I just happened across this newsgroup and was reading from the beginning.
>
>Sean Fritz
>
>