• stonecobra (30/30) Jul 29 2004 I have an interface Collection that defines a few methods:
• stonecobra (3/14) Jul 29 2004 How did DWT deal with this? Does SWT have any abstract classes?
• stonecobra (6/27) Jul 29 2004 What's even more confusing (to me) is if I add:
• parabolis (10/58) Jul 29 2004 This is not a bug. For a long answer your should look for the

stonecobra <scott stonecobra.com> writes:

I have an interface Collection that defines a few methods:

int size();
bool contains(Object foo);
bool equals(Object foo);
etc.

Now I have a class, AbstractCollection that almost implements the 
Collection interface:

class AbstractCollection : Collection {

//implement everything but equals()

}

Now, I run DMD, and get:

util.d(111): class AbstractCollection 1interface function 
Collection.equals is not implemented

Fair enough.  Off topic, is that 1 supposed to be there in the error 
message before 'interface'?

So, I change the class to be abstract:

abstract class AbstractCollection : Collection {...

Still no dice.  What I found with tinkering is that I either have to

1. add a 'bool equals(Object foo);' to the class

or

2. Not call the class abstract and add a:
   abstract bool equals(Object foo);

inside the body of the class.

Since I am doing source level Java translation, this is an issue for me 
to find out all the methods that I have not implemented and stub them 
out without implementation.  Shouldn't the 'abstract class Foo' tell the 
compiler that the contract is not going to be fulfilled?

Walter, is this a bug or intended behavior?

Thanks
Scott Sanders

stonecobra <scott stonecobra.com> writes:

stonecobra wrote:
 class AbstractCollection : Collection {
 
 //implement everything but equals()
 
 }
 
 Now, I run DMD, and get:
 
 util.d(111): class AbstractCollection 1interface function 
 Collection.equals is not implemented
 

How did DWT deal with this?  Does SWT have any abstract classes?

Scott

stonecobra <scott stonecobra.com> writes:

stonecobra wrote:
 I have an interface Collection that defines a few methods:
 
 int size();
 bool contains(Object foo);
 bool equals(Object foo);
 etc.
 
 Now I have a class, AbstractCollection that almost implements the 
 Collection interface:
 
 class AbstractCollection : Collection {
 
 //implement everything but equals()
 
 }
 
 Now, I run DMD, and get:
 
 util.d(111): class AbstractCollection 1interface function 
 Collection.equals is not implemented
 

What's even more confusing (to me) is if I add:

bool equals();

The compiler stops complaining.  Note the lack of a parameter there?

Can someone explain this to me?

Scott Sanders

parabolis <parabolis softhome.net> writes:

This is not a bug. For a long answer your should look for the 
thread "Three notable problems with method name resolution."

What is happening here is the compiler will not accept the 
inherited function .equals(Object) as satisfying the Interface 
as Java does. So you have to add a stub function:
================================================================
     class AbstractCollection : Collection {
         bit equals( Object obj ) { return super(obj); }
================================================================



stonecobra wrote:

 I have an interface Collection that defines a few methods:
 
 int size();
 bool contains(Object foo);
 bool equals(Object foo);
 etc.
 
 Now I have a class, AbstractCollection that almost implements the 
 Collection interface:
 
 class AbstractCollection : Collection {
 
 //implement everything but equals()
 
 }
 
 Now, I run DMD, and get:
 
 util.d(111): class AbstractCollection 1interface function 
 Collection.equals is not implemented
 
 Fair enough.  Off topic, is that 1 supposed to be there in the error 
 message before 'interface'?
 
 So, I change the class to be abstract:
 
 abstract class AbstractCollection : Collection {...
 
 Still no dice.  What I found with tinkering is that I either have to
 
 1. add a 'bool equals(Object foo);' to the class
 
 or
 
 2. Not call the class abstract and add a:
   abstract bool equals(Object foo);
 
 inside the body of the class.
 
 Since I am doing source level Java translation, this is an issue for me 
 to find out all the methods that I have not implemented and stub them 
 out without implementation.  Shouldn't the 'abstract class Foo' tell the 
 compiler that the contract is not going to be fulfilled?
 
 Walter, is this a bug or intended behavior?
 
 Thanks
 Scott Sanders