John Demme wrote:
> Walter Bright wrote:
> 
>> "John Demme" <me@teqdruid.com> wrote in message
>> news:dq9r0a$1u46$1@digitaldaemon.com...
>>> Sure it'd be nice if Walter would fix some of these issues, but first he
>>> has
>>> to be convinced that there are issues, something which I've had no
>>> success in doing.
>> I think I've found a way to make the covariance thing work, so stay tuned.
> 
> Great; thanks.
> 
> Just out of curiosity, what made you take this issue up now instead of
> earlier (or later)?
> 
> ~John Demme


Uh... it's okay Walter, um... don't listen to him... he didn't mean it, honest!

<* grabs John Demme, stuffs a sock in his mouth, and drags him away... before Walter changes his mind *>

;)

-JJR

John Reimer wrote:

> John Demme wrote:
>> Walter Bright wrote:
>> 
>>> "John Demme" <me@teqdruid.com> wrote in message news:dq9r0a$1u46$1@digitaldaemon.com...
>>>> Sure it'd be nice if Walter would fix some of these issues, but first
>>>> he has
>>>> to be convinced that there are issues, something which I've had no
>>>> success in doing.
>>> I think I've found a way to make the covariance thing work, so stay tuned.
>> 
>> Great; thanks.
>> 
>> Just out of curiosity, what made you take this issue up now instead of
>> earlier (or later)?
>> 
>> ~John Demme
> 
> 
> Uh... it's okay Walter, um... don't listen to him... he didn't mean it, honest!
> 
> <* grabs John Demme, stuffs a sock in his mouth, and drags him away... before Walter changes his mind *>
> 
> ;)
> 
> -JJR

I'm sorry... I didn't mean anything by it... Should I reword to:
Great! Thanks!
I thought that the exclamation marks might seem sarcastic.

And I really was just curious what prompted Walter to bring up the issue now, considering that I haven't mentioned in awhile....

Didn't mean anything by my post-- certainly not anything negative.

~John Demme

John Demme wrote:
> John Reimer wrote:
> 
>> John Demme wrote:
>>> Walter Bright wrote:
>>>
>>>> "John Demme" <me@teqdruid.com> wrote in message
>>>> news:dq9r0a$1u46$1@digitaldaemon.com...
>>>>> Sure it'd be nice if Walter would fix some of these issues, but first
>>>>> he has
>>>>> to be convinced that there are issues, something which I've had no
>>>>> success in doing.
>>>> I think I've found a way to make the covariance thing work, so stay
>>>> tuned.
>>> Great; thanks.
>>>
>>> Just out of curiosity, what made you take this issue up now instead of
>>> earlier (or later)?
>>>
>>> ~John Demme
>>
>> Uh... it's okay Walter, um... don't listen to him... he didn't mean it,
>> honest!
>>
>> <* grabs John Demme, stuffs a sock in his mouth, and drags him away...
>> before Walter changes his mind *>
>>
>> ;)
>>
>> -JJR
> 
> I'm sorry... I didn't mean anything by it... Should I reword to:
> Great! Thanks!
> I thought that the exclamation marks might seem sarcastic.
> 
> And I really was just curious what prompted Walter to bring up the issue
> now, considering that I haven't mentioned in awhile....
> 
> Didn't mean anything by my post-- certainly not anything negative.
> 
> ~John Demme


I, in turn, apologize for being rediculous. It was all in good fun, John.  You had a valid question.  I just couldn't help playing on it a bit.  I think I over did it!  I'm curious too what prompted Walter's response, but I imagine it just had to do with him finally catching up to this post after all this time. :P

Sorry, man.  I must have been just a little too giddy.

-JJR

In article <dqoho0$bmh$1@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

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@digitaldaemon.com>, sean.fritz@gmail.com says...
>
>In article <dqoho0$bmh$1@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
>
>

In article <e798bq$2gmi$1@digitaldaemon.com>, michal.minich@gmail.com says...
>
>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);
>}

Does B also have a method/function (which do I use with D?) compareTo(A o)?

Sean

Sean Fritz wrote:
> Does B also have a method/function (which do I use with D?) compareTo(A o)?
> 

"A virtual member function is sometimes called a /method/." -Bjarne Stroustrup, The C++ Programming Language 3rd ed, section 12.2.6

In D, whether or not a member function is virtual is typically up to the compiler. In a sense, the distinction does not matter in D, unless you start declaring member functions as "final," which is basically saying "this is not virtual." This behavior is functionally similar to Java, in which all member functions are virtual; thus the term "method" is preferred in that language.

"Member function" will always work, and "method" is usually fine in D. You'll usually catch me using "member function" by default, as I come from a C++ background.

-Kirk McDonald

You have to write:
(cast(A)b).compareTo(a);

In case you use only b.compareTo(a); D issues an error, because the method comparetTo in class B hides the implementation of this method in class a, so the parameters of type B cannot be casted to A.

btw. (OT?) in C# is very nice possibility to imlement more interfaces in one class with the same method signature. I don't know if this is possible in Java...?

interface IA { void foo() }
interface IB { void foo() }
interface IC { void foo() }

class D : IA, IB, IC
{
void IA.foo () {} // explicitly implements foo() in interface IA
void foo () {} // implicitly implements foo() in interface IB
void IC.foo () {} // explicitly implements foo() in interface IC
}

void main ()
{
D d = new D();
d.foo() // calls foo implementing IB interface
((IA)d).foo () // calls foo implementing IA interface
((IB)d).foo () // calls foo implementing IA interface
}

I think the reason for this in C# is to solve problems where class have to implement two absolutely different interface, but it happens that they have the same method signature. It would be nice to have this possiblity in D.





In article <e79q4g$c4d$1@digitaldaemon.com>, Sean Fritz says...
>
>In article <e798bq$2gmi$1@digitaldaemon.com>, michal.minich@gmail.com says...
>>
>>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);
>>}
>
>Does B also have a method/function (which do I use with D?) compareTo(A o)?
>
>Sean
>
>