class A
{
  protected void test()
  {
    printf ("A");
  }
}

class B
{
   private override void test()
   {
    printf ("B");
   }
}

main()
{
  B b = new B;
  b.test();
}

output: A

No compile error; nothing; Nada. Simple typing mistake while refactoring. So much for "override" catching bugs.

On Wed, 4 Aug 2004 17:18:30 -0700, Mickey Finn wrote:

> class A
> {
>   protected void test()
>   {
>     printf ("A");
>   }
> }
> 
> class B
> {
>    private override void test()
>    {
>     printf ("B");
>    }
> }
> 
> main()
> {
>   B b = new B;
>   b.test();
> }
> 
> output: A
> 
> No compile error; nothing; Nada. Simple typing mistake while refactoring. So much for "override" catching bugs.

I just tried your example and I get the output "B". Also, the override attribute is only meant to be used on virtual functions. I quote the manual...

"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. The override attribute is useful for catching errors when a base class's member function gets its parameters changed, and all derived classes need to have their overriding functions updated."


-- 
Derek
Melbourne, Australia
5/Aug/04 10:40:13 AM

Oops; typed up the contrived example just to illustrate the issue, but it's a sneakier bug than first noted. Here's an example that was actually executed:

class A
{
  protected void create()
  {
    printf ("A");
  }

  void test()
  {
        create();
  }
}

class B : A
{
   private override void create()
   {
    printf ("B");
   }
}

void main()
{
  B b = new B;
  b.test();
}

Output: A

I repeat: no compile error; nothing; nada. Simple typing mistake while refactoring. So much for "override" catching bugs.

On Wed, 4 Aug 2004 18:31:29 -0700, Mickey Finn <horizon@blackhole.net> wrote:

> Oops; typed up the contrived example just to illustrate the issue, but it's
> a sneakier bug than first noted. Here's an example that was actually
> executed:
>
> class A
> {
>   protected void create()
>   {
>     printf ("A");
>   }
>
>   void test()
>   {
>         create();
>   }
> }
>
> class B : A
> {
>    private override void create()
>    {
>     printf ("B");
>    }
> }
>
> void main()
> {
>   B b = new B;
>   b.test();
> }
>
> Output: A
>
> I repeat: no compile error; nothing; nada. Simple typing mistake while
> refactoring. So much for "override" catching bugs.

You know it's the fact that one method is private and the other protected, right?

Were they that way in the original class, if so, wasn't it a bug there too? If not what was the point? (I have not done enough C++ to see it)

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsb8lkppu5a2sq9@digitalmars.com...
> On Wed, 4 Aug 2004 18:31:29 -0700, Mickey Finn <horizon@blackhole.net>
> wrote:
> You know it's the fact that one method is private and the other protected,
> right?

Yep. That's the point. If you remove the "private" it works as expected. The point is that override is meant to catch this, but didn't.

> Were they that way in the original class, if so, wasn't it a bug there too? If not what was the point? (I have not done enough C++ to see it)

No, they weren't. This was a classic case of  "ahh, that method probably shoudn't be exposed at this level; let's make it private". However, the compiler then (a) ignored the method in B even though it should still invoke it, and (b) "override" played dumb.

Further, there's the valid notion that this was deliberately attempting to restrict visibility on that particular method. But that's a different topic, because this one is about "override" not catching the issue; and that alone.

On Wed, 4 Aug 2004 19:46:43 -0700, Mickey Finn <horizon@blackhole.net> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsb8lkppu5a2sq9@digitalmars.com...
>> On Wed, 4 Aug 2004 18:31:29 -0700, Mickey Finn <horizon@blackhole.net>
>> wrote:
>> You know it's the fact that one method is private and the other protected,
>> right?
>
> Yep. That's the point. If you remove the "private" it works as expected.

I know.

I am simply pointing out the bug might not be in 'override' itself, but in the resolution of the function call.

> The
> point is that override is meant to catch this, but didn't.

I think override _is_ working, but function resolution is not.

>> Were they that way in the original class, if so, wasn't it a bug there
>> too? If not what was the point? (I have not done enough C++ to see it)
>
> No, they weren't. This was a classic case of  "ahh, that method probably
> shoudn't be exposed at this level; let's make it private". However, the
> compiler then (a) ignored the method in B even though it should still invoke
> it

This is the bug.

> , and (b) "override" played dumb.

If you assume (a) then override was in fact correct.

> Further, there's the valid notion that this was deliberately attempting to
> restrict visibility on that particular method. But that's a different topic,
> because this one is about "override" not catching the issue; and that alone.


Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Regan; Derek; I'm just trying to report a bug ... not have a pseudo-philosophical debate. I'll leave it up to the compiler author to determine exactly what the root cause is, and how to fix it. Is that acceptable?


"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsb8ribzv5a2sq9@digitalmars.com...
> On Wed, 4 Aug 2004 19:46:43 -0700, Mickey Finn <horizon@blackhole.net> wrote:
> > "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsb8lkppu5a2sq9@digitalmars.com...
> >> On Wed, 4 Aug 2004 18:31:29 -0700, Mickey Finn <horizon@blackhole.net>
> >> wrote:
> >> You know it's the fact that one method is private and the other
> >> protected,
> >> right?
> >
> > Yep. That's the point. If you remove the "private" it works as expected.
>
> I know.
>
> I am simply pointing out the bug might not be in 'override' itself, but in the resolution of the function call.
>
> > The
> > point is that override is meant to catch this, but didn't.
>
> I think override _is_ working, but function resolution is not.
>
> >> Were they that way in the original class, if so, wasn't it a bug there too? If not what was the point? (I have not done enough C++ to see it)
> >
> > No, they weren't. This was a classic case of  "ahh, that method probably
> > shoudn't be exposed at this level; let's make it private". However, the
> > compiler then (a) ignored the method in B even though it should still
> > invoke
> > it
>
> This is the bug.
>
> > , and (b) "override" played dumb.
>
> If you assume (a) then override was in fact correct.
>
> > Further, there's the valid notion that this was deliberately attempting
> > to
> > restrict visibility on that particular method. But that's a different
> > topic,
> > because this one is about "override" not catching the issue; and that
> > alone.
>
>
> Regan
>
> --
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Wed, 4 Aug 2004 21:39:15 -0700, Mickey Finn <horizon@blackhole.net> wrote:
> Regan; Derek; I'm just trying to report a bug ... not have a
> pseudo-philosophical debate. I'll leave it up to the compiler author to
> determine exactly what the root cause is, and how to fix it. Is that
> acceptable?

Sure, whatever floats your boat man.
Regan

> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsb8ribzv5a2sq9@digitalmars.com...
>> On Wed, 4 Aug 2004 19:46:43 -0700, Mickey Finn <horizon@blackhole.net>
>> wrote:
>> > "Regan Heath" <regan@netwin.co.nz> wrote in message
>> > news:opsb8lkppu5a2sq9@digitalmars.com...
>> >> On Wed, 4 Aug 2004 18:31:29 -0700, Mickey Finn 
>> <horizon@blackhole.net>
>> >> wrote:
>> >> You know it's the fact that one method is private and the other
>> >> protected,
>> >> right?
>> >
>> > Yep. That's the point. If you remove the "private" it works as 
>> expected.
>>
>> I know.
>>
>> I am simply pointing out the bug might not be in 'override' itself, but in
>> the resolution of the function call.
>>
>> > The
>> > point is that override is meant to catch this, but didn't.
>>
>> I think override _is_ working, but function resolution is not.
>>
>> >> Were they that way in the original class, if so, wasn't it a bug 
>> there
>> >> too? If not what was the point? (I have not done enough C++ to see 
>> it)
>> >
>> > No, they weren't. This was a classic case of  "ahh, that method 
>> probably
>> > shoudn't be exposed at this level; let's make it private". However, 
>> the
>> > compiler then (a) ignored the method in B even though it should still
>> > invoke
>> > it
>>
>> This is the bug.
>>
>> > , and (b) "override" played dumb.
>>
>> If you assume (a) then override was in fact correct.
>>
>> > Further, there's the valid notion that this was deliberately 
>> attempting
>> > to
>> > restrict visibility on that particular method. But that's a different
>> > topic,
>> > because this one is about "override" not catching the issue; and that
>> > alone.
>>
>>
>> Regan
>>
>> --
>> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Wed, 4 Aug 2004 21:39:15 -0700, Mickey Finn wrote:

> Regan; Derek; I'm just trying to report a bug ... not have a pseudo-philosophical debate. I'll leave it up to the compiler author to determine exactly what the root cause is, and how to fix it. Is that acceptable?

Didn't know that's what I was doing, but hey! whatever. No skin off my knees.

I still think that there is no bug and it's your attempted usage that is the issue. The docs say "virtual" functions only and you are not using it with virtual functions - so call me silly.

-- 
Derek
Melbourne, Australia
5/Aug/04 4:17:40 PM

I also tried this example before the other version was posted. Even so, it points out another problem with "override":  as soon as you add "private" to the "override" method, the mechanism breaks. For example, you should not have been able to compile without error purely because (in the bogus example) B.test did /not/ override anything, as you pointed out. The "private" keyword somehow disables that functionality. Same thing happens when using the "package" keyword too. something is not right here.


"Derek Parnell" <derek@psych.ward> wrote in message news:cervok$o5k$1@digitaldaemon.com...
> On Wed, 4 Aug 2004 17:18:30 -0700, Mickey Finn wrote:
>
> > class A
> > {
> >   protected void test()
> >   {
> >     printf ("A");
> >   }
> > }
> >
> > class B
> > {
> >    private override void test()
> >    {
> >     printf ("B");
> >    }
> > }
> >
> > main()
> > {
> >   B b = new B;
> >   b.test();
> > }
> >
> > output: A
> >
> > No compile error; nothing; Nada. Simple typing mistake while
refactoring. So
> > much for "override" catching bugs.
>
> I just tried your example and I get the output "B". Also, the override attribute is only meant to be used on virtual functions. I quote the manual...
>
> "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. The override attribute is useful for catching errors when a base class's member function gets its parameters changed, and all derived classes need to have their overriding functions updated."
>
>
> --
> Derek
> Melbourne, Australia
> 5/Aug/04 10:40:13 AM