www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3258] New: Calling private or package override methods calls the base implementation

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3258

           Summary: Calling private or package override methods calls the
                    base implementation
           Product: D
           Version: 1.045
          Platform: x86
        OS/Version: Linux
            Status: NEW
          Keywords: accepts-invalid, wrong-code
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: diggory.hardy gmail.com


(Same as: http://www.dsource.org/projects/ldc/ticket/355
Exactly the same problem with dmd 1.045, dmd 2.031, ldc 0.9.1.)

Probably related to #354, when overriding methods with an implementation in a
base class, from a reference of type base class, the wrong implementations get
called.

OK, so overriding private functions is illegal according to the spec, but since
the compiler doesn't complain, I included those to show the similarity between
package and private functions (same error with both).

{{{
#!d
// Declare and define some methods...
class A {
    private void iPriv ()    { assert(false, "iPriv"); }
    protected void iProt ()    { assert(false, "iProt"); }
    package void iPack ()    { assert(false, "iPack"); }
    public void iPub ()        { assert(false, "iPub"); }
}

// ... but override them all here:
class B : A {
    private override void iPriv() {}    // (lesser issue: shouldn't the
compiler complain here?)
    protected override void iProt() {}
    package override void iPack() {}
    public override void iPub() {}
}

void main() {
    // None of these assert of course (overriden functions are called):
    B b = new B;
    b.iPriv;
    b.iProt;
    b.iPack;
    b.iPub;

    // But when we call from a base class with an implementation:
    A a = b;
    a.iPriv;    // This calls A.iPriv and asserts
    a.iProt;
    a.iPack;    // This calls A.iPack and asserts
    a.iPub;
}
}}}
Unless the {{{a.iPriv;}}} and {{{a.iPack;}}} calls are removed, the program
asserts when run.

 1. With private functions this is nearly OK, but the compiler should complain
about trying to override them instead of silently calling the base
implementation.
 2. With package protection, the wrong implementation of iPack() is called.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 18 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3258


Stewart Gordon <smjg iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com




--- Comment #1 from Stewart Gordon <smjg iname.com>  2009-08-19 12:41:34 PDT ---
private and package methods aren't virtual and so don't override.  There should
be something in the spec to this effect, but I can't seem to find it.  The bug
is that the compiler accepts the override attribute on these, simple as that.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 19 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3258


Matti Niemenmaa <matti.niemenmaa+dbugzilla iki.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matti.niemenmaa+dbugzilla i
                   |                            |ki.fi




--- Comment #2 from Matti Niemenmaa <matti.niemenmaa+dbugzilla iki.fi> 
2009-08-19 13:32:06 PDT ---
http://www.digitalmars.com/d/1.0/attribute.html#ProtectionAttribute says:
"Private members cannot be overridden."

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 19 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3258





--- Comment #3 from Diggory <diggory.hardy gmail.com>  2009-08-19 23:14:26 PDT
---
With private functions, yes. But I've never heard that package functions can't
be virtual. Stewart Gordan, are you saying package functions aren't virtual by
design (I hope not), or that this is just the current implementation?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 19 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3258


Jarrett Billingsley <jarrett.billingsley gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jarrett.billingsley gmail.c
                   |                            |om




--- Comment #4 from Jarrett Billingsley <jarrett.billingsley gmail.com> 
2009-08-19 23:47:28 PDT ---
(In reply to comment #3)
 With private functions, yes. But I've never heard that package functions can't
 be virtual. Stewart Gordan, are you saying package functions aren't virtual by
 design (I hope not), or that this is just the current implementation?

Whether it's by design or not is not entirely clear. The only thing the spec says about 'package' in this regard is that it is basically an extension of 'private', in which case it makes sense (in a strange way) that 'package' would make a method nonvirtual. But it just seems like it's conflating two entirely different concepts: access and virtuality. Private methods can and should be nonvirtual, since that's a valid optimization. But it's entirely reasonable to have a package method that can be overridden. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 19 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3258


Mike Shulman <viritrilbia+d gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |viritrilbia+d gmail.com


--- Comment #5 from Mike Shulman <viritrilbia+d gmail.com> 2011-06-03 20:48:04
PDT ---
Since private methods are visible to the entire module in which they are
defined, and thus could reasonably be overridden by derived classes defined in
the same module, I don't see why making them all non-virtual is any more valid
of an optimization, in principle, than doing the same for package methods.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 03 2011