http://d.puremagic.com/issues/show_bug.cgi?id=3258



--- Comment #10 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2012-12-21 17:04:28 PST ---
(In reply to comment #9)
> Non-virtual by default + a virtual keyword + no limits on virtuality based on access specifiers => dream come true (for me).

I forgot one thing that completes the circle, and that is friend declarations. That way private inheritance actually becomes useful beyond the module the class is declared in. I never liked the idea of having private leak into the entire module to begin with, I want fine-grained access via friend declarations and access specifiers which don't mess with virtuality. Otherwise I'm left using PIMPL idioms or mixin templates (yuck!).

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

http://d.puremagic.com/issues/show_bug.cgi?id=3258



--- Comment #11 from Stewart Gordon <smjg@iname.com> 2012-12-21 17:14:10 PST ---
(In reply to comment #10)
> I forgot one thing that completes the circle, and that is friend declarations.

There are no friend declarations in D.  So what exactly are you talking about?

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

http://d.puremagic.com/issues/show_bug.cgi?id=3258



--- Comment #12 from Diggory <diggory.hardy@gmail.com> 2012-12-22 02:26:22 PST ---
(In reply to comment #11)
> (In reply to comment #10)
> > I forgot one thing that completes the circle, and that is friend declarations.
> 
> There are no friend declarations in D.  So what exactly are you talking about?

Look up friend classes/functions in C++ and his meaning should be clear.

For the problem at hand though, without causing a lot of breakage, that means either private/package become virtual by default, private/package can never be virtual, or a 'virtual' (or 'overridable') keyword is introduced. In theory I agree with Andrej, but would probably vote that handling all protection methods in the same way is preferable.

In an ideal world though, I think I'd choose to make overriding explicit and shadowing illegal: i.e. unless 'virtual'/'override' is specified names must not clash with those from a base class.

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

http://d.puremagic.com/issues/show_bug.cgi?id=3258



--- Comment #13 from Stewart Gordon <smjg@iname.com> 2012-12-22 03:56:58 PST ---
(In reply to comment #12)
> For the problem at hand though, without causing a lot of breakage, that means either private/package become virtual by default, private/package can never be virtual, or a 'virtual' (or 'overridable') keyword is introduced.  In theory I agree with Andrej, but would probably vote that handling all protection methods in the same way is preferable.

At the moment, we have final, which is roughly the negation of virtual.

> In an ideal world though, I think I'd choose to make overriding explicit and shadowing illegal: i.e.  unless 'virtual'/'override' is specified names must not clash with those from a base class.

I agree that it would be a way forward to kill overriding without the override attribute once and for all.  Once this is done, we can implement this principle:

- If a private symbol is redeclared in a subclass in the same module, it must have the override attribute, and it overrides the superclass method.

- If a private symbol is redeclared in a subclass in a different module, it must not have the override attribute, and the two are distinct symbols with no relation to each other.  Basically, the subclass has no knowledge of the superclass's private members (as it should be).

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