• Bill Baxter (29/29) Apr 22 2007 I think this may be a bug with super-interfaces.
• Chris Nicholson-Sauls (6/43) Apr 24 2007 I don't think it is. As I understand it, 'override' only masks a virtua...
• Bill Baxter (15/61) Apr 24 2007 Huh, well I routinely use override on things I inherit from interfaces.
• Chris Nicholson-Sauls (7/72) Apr 26 2007 Essentially... yeah. :) Quoting the 'Attributes' page:

Bill Baxter <dnewsgroup billbaxter.com> writes:

I think this may be a bug with super-interfaces.
It's telling me that something is not an override, when, in fact, it is.

Here's the setup:

interface Fruit
{
    ...  // some methods
}
interface Vehicle
{
    void drive_around();
    ...  // some other methods
}
interface MobileFruit : Fruit, Vehicle
{
    // nothing here, should inherit from superinterfaces
}

class BaseFruit : Fruit
{
    // implement (some of) Fruit's methods here
}

class MobileFruitGundam : BaseFruit, MobileFruit
{
    // implement what's not in BaseFruit already

    override void drive_around() {..} // from Vehicle
}

The last part doesn't work.  It tells me that drive_around is not an 
override.  But it works if I don't tag it with 'override'.

Is that a bug?

--bb

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

Bill Baxter wrote:
 I think this may be a bug with super-interfaces.
 It's telling me that something is not an override, when, in fact, it is.
 
 Here's the setup:
 
 interface Fruit
 {
    ...  // some methods
 }
 interface Vehicle
 {
    void drive_around();
    ...  // some other methods
 }
 interface MobileFruit : Fruit, Vehicle
 {
    // nothing here, should inherit from superinterfaces
 }
 
 class BaseFruit : Fruit
 {
    // implement (some of) Fruit's methods here
 }
 
 class MobileFruitGundam : BaseFruit, MobileFruit
 {
    // implement what's not in BaseFruit already
 
    override void drive_around() {..} // from Vehicle
 }
 
 The last part doesn't work.  It tells me that drive_around is not an 
 override.  But it works if I don't tag it with 'override'.
 
 Is that a bug?
 
 --bb

I don't think it is.  As I understand it, 'override' only masks a virtual
function 
implementation or 'abstract' placeholder.  Interfaces do not provide
implementations nor 
placeholders, only a contract requiring certain signatures exist.  The main use
of 
'override' is to catch non-back-compatible API changes.

-- Chris Nicholson-Sauls

Bill Baxter <dnewsgroup billbaxter.com> writes:

Chris Nicholson-Sauls wrote:
 Bill Baxter wrote:
 I think this may be a bug with super-interfaces.
 It's telling me that something is not an override, when, in fact, it is.

 Here's the setup:

 interface Fruit
 {
    ...  // some methods
 }
 interface Vehicle
 {
    void drive_around();
    ...  // some other methods
 }
 interface MobileFruit : Fruit, Vehicle
 {
    // nothing here, should inherit from superinterfaces
 }

 class BaseFruit : Fruit
 {
    // implement (some of) Fruit's methods here
 }

 class MobileFruitGundam : BaseFruit, MobileFruit
 {
    // implement what's not in BaseFruit already

    override void drive_around() {..} // from Vehicle
 }

 The last part doesn't work.  It tells me that drive_around is not an 
 override.  But it works if I don't tag it with 'override'.

 Is that a bug?

 --bb

 
 I don't think it is.  As I understand it, 'override' only masks a 
 virtual function implementation or 'abstract' placeholder.  Interfaces 
 do not provide implementations nor placeholders, only a contract 
 requiring certain signatures exist.  The main use of 'override' is to 
 catch non-back-compatible API changes.
 
 -- Chris Nicholson-Sauls

Huh, well I routinely use override on things I inherit from interfaces.

This generates no errors:
interface Fruit
{
     void eat();
}
class YummyFruit : Fruit
{
     override void eat() {
        writefln("That's yummy");
     }
}

So you're opinion is that the spec says that should be an error?

--bb

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

Bill Baxter wrote:
 Chris Nicholson-Sauls wrote:
 Bill Baxter wrote:
 I think this may be a bug with super-interfaces.
 It's telling me that something is not an override, when, in fact, it is.

 Here's the setup:

 interface Fruit
 {
    ...  // some methods
 }
 interface Vehicle
 {
    void drive_around();
    ...  // some other methods
 }
 interface MobileFruit : Fruit, Vehicle
 {
    // nothing here, should inherit from superinterfaces
 }

 class BaseFruit : Fruit
 {
    // implement (some of) Fruit's methods here
 }

 class MobileFruitGundam : BaseFruit, MobileFruit
 {
    // implement what's not in BaseFruit already

    override void drive_around() {..} // from Vehicle
 }

 The last part doesn't work.  It tells me that drive_around is not an 
 override.  But it works if I don't tag it with 'override'.

 Is that a bug?

 --bb

 I don't think it is.  As I understand it, 'override' only masks a 
 virtual function implementation or 'abstract' placeholder.  Interfaces 
 do not provide implementations nor placeholders, only a contract 
 requiring certain signatures exist.  The main use of 'override' is to 
 catch non-back-compatible API changes.

 -- Chris Nicholson-Sauls

 
 Huh, well I routinely use override on things I inherit from interfaces.
 
 This generates no errors:
 interface Fruit
 {
     void eat();
 }
 class YummyFruit : Fruit
 {
     override void eat() {
        writefln("That's yummy");
     }
 }
 
 So you're opinion is that the spec says that should be an error?
 
 --bb

Essentially... yeah.  :)  Quoting the 'Attributes' page:
"""The override attribute applies to virtual functions. It means that the
function must 
override a function with the same name and parameters in a base class."""

So, to me, that means interfaces are excluded from 'override's behavior. 
Although the 
fact that your simpler example works makes me wonder.  (I'd never actually
tried it.)

-- Chris Nicholson-Sauls