www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - bug with abstract class

reply stonecobra <scott stonecobra.com> writes:
Using DMD 0.97,  I am creating a collections hierarchy, and boiled the 
code down to this:

interface Map {
   bool equals(Object o);
   int size();
}

abstract class AbstractMap : Map {
   int size() { return 0;}
}

abstract class HashMap : AbstractMap {
   bool equals(Object o) { return true; }
}


when I compile it, I get:

interface.d(6): class AbstractMap 1interface function Map.equals is not 
implemented

Of course, it is not implemented!  AbstractMap is an abstract class.

Thanks
Scott Sanders
Jul 29 2004
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 29 Jul 2004 20:14:17 -0700, stonecobra wrote:


 Using DMD 0.97,  I am creating a collections hierarchy, and boiled the 
 code down to this:
 
 interface Map {
    bool equals(Object o);
    int size();
 }
 
 abstract class AbstractMap : Map {
    int size() { return 0;}
 }
 
 abstract class HashMap : AbstractMap {
    bool equals(Object o) { return true; }
 }
 
 when I compile it, I get:
 
 interface.d(6): class AbstractMap 1interface function Map.equals is not 
 implemented
 
 Of course, it is not implemented!  AbstractMap is an abstract class.


Maybe 'implemented' is the wrong term to use in this message. It could read
"interface.d(6): class AbstractMap. The interface function 'Map.equals' has
not been included in the definition of class 'AbstractMap'".

Every, yes - *every*, method mentioned in an interface /must/ be also
explicitly mentioned in any class that is based on that interface.

So if you don't want AbstractMap to contain equals() [abstract or
otherwise], then don't include it in the Map interface. Make two
interfaces, one for size() and the other for equals().


 interface iMap_size {
    int size();
 }
 
 interface iMap_eq {
    bool equals(Object o);
 }
 
 abstract class AbstractMap : iMap_size {
    int size() { return 0;}
 }
 
 abstract class HashMap : AbstractMap, iMap_eq {
    bool equals(Object o) { return true; }
 }




-- 
Derek
Melbourne, Australia
30/Jul/04 1:43:22 PM
Jul 29 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Fri, 30 Jul 2004 13:53:38 +1000, Derek Parnell <derek psych.ward> wrote:


 On Thu, 29 Jul 2004 20:14:17 -0700, stonecobra wrote:


 Using DMD 0.97,  I am creating a collections hierarchy, and boiled the
 code down to this:

 interface Map {
    bool equals(Object o);
    int size();
 }

 abstract class AbstractMap : Map {
    int size() { return 0;}
 }

 abstract class HashMap : AbstractMap {
    bool equals(Object o) { return true; }
 }

 when I compile it, I get:

 interface.d(6): class AbstractMap 1interface function Map.equals is not
 implemented

 Of course, it is not implemented!  AbstractMap is an abstract class.


 Maybe 'implemented' is the wrong term to use in this message. It could 
 read
 "interface.d(6): class AbstractMap. The interface function 'Map.equals' 
 has
 not been included in the definition of class 'AbstractMap'".

 Every, yes - *every*, method mentioned in an interface /must/ be also
 explicitly mentioned in any class that is based on that interface.

 So if you don't want AbstractMap to contain equals() [abstract or
 otherwise], then don't include it in the Map interface. Make two
 interfaces, one for size() and the other for equals().


  interface iMap_size {
     int size();
  }

  interface iMap_eq {
     bool equals(Object o);
  }

  abstract class AbstractMap : iMap_size {
     int size() { return 0;}
  }

  abstract class HashMap : AbstractMap, iMap_eq {
     bool equals(Object o) { return true; }
  }


Actually I think the correct soln is to move the Interface from the 
abstract class to the non-abstract one eg.

interface Map {
    bool equals(Object o);
    int size();
}

abstract class AbstractMap {
    int size() { return 0;}
}

abstract class HashMap : AbstractMap, Map {
    bool equals(Object o) { return true; }
}

However, this will give the same or similar message as Parent class 
methods do not satisfy an interface, IMO this kinda defeats the 
purpose/idea of interfaces*. I am hoping Walter can change it so as parent 
methods do satisfy interfaces.

To avoid the message refactor as Derek has shown. **this refactoring 
defeats the purpose/idea of interfaces, which is that the interface design 
need no be mirrored in the class design, that is you can have one 
interface, satisfied by methods from more than one class.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 29 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"stonecobra" <scott stonecobra.com> wrote in message
news:cecee2$22it$1 digitaldaemon.com...

 when I compile it, I get:

 interface.d(6): class AbstractMap 1interface function Map.equals is not
 implemented

 Of course, it is not implemented!  AbstractMap is an abstract class.


Try this:

interface Map {
   bool equals(Object o);
   int size();
}

abstract class AbstractMap : Map {
   int size() { return 0;}
   abstract bool equals(Object o);
}


abstract class HashMap : AbstractMap {
   bool equals(Object o) { return true; }
}


where you let the compiler know that you're 'deferring' implementing equals
by making an abstract declaration of it.
Jul 29 2004
parent stonecobra <scott stonecobra.com> writes:
Walter wrote:


 "stonecobra" <scott stonecobra.com> wrote in message
 news:cecee2$22it$1 digitaldaemon.com...
 

when I compile it, I get:

interface.d(6): class AbstractMap 1interface function Map.equals is not
implemented

Of course, it is not implemented!  AbstractMap is an abstract class.


 
 
 Try this:
 
 interface Map {
    bool equals(Object o);
    int size();
 }
 
 abstract class AbstractMap : Map {
    int size() { return 0;}
    abstract bool equals(Object o);
 }
 
 
 abstract class HashMap : AbstractMap {
    bool equals(Object o) { return true; }
 }
 
 
 where you let the compiler know that you're 'deferring' implementing equals
 by making an abstract declaration of it.
 
 


So, you are saying that I will always have to declare abstract at a 
method level?  That hurts...

Scott
Jul 30 2004