[Issue 3258] Calling private or package override methods calls the base implementation

[d-bugmail at puremagic.com]

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



--- Comment #9 from Andrej Mitrovic <andrej.mitrovich at gmail.com> 2012-12-21 15:09:12 PST ---
(In reply to comment #7)
>

Yeah I know, the spec tells one thing on one page, then another thing on
another. It says "Package extends private" on the protection attributes page,
implying it's final like private.

Small note: In terms of the compiler implementation, the private and package
set to non-virtual boils down to a single `if` check in the front-end.

Forcing private and package non-virtual must have a rationale in the spec.
There isn't one, so Walter and Andrei should state exactly why this decision
was made.

Actually, Walter and Andrei obviously had a miscommunication, because Andrei
expected private to allow being virtual in TDPL. And 'package' being
non-virtual isn't mentioned in TDPL either (lots of people get confused by
this). So maybe Walter is the one to write the rationale.

I also believe it's not too late to change the state of things. We have the
`final` keyword after all. Yes, making private and package virtual could
potentially slow down code, but fixing it is trivial, it just requires a
`final` keyword. Perhaps the the compiler can be made smart enough to optimize
non-overriden private/package methods so they're made final. Maybe if -lib or
-c are not used it can do such optimizations.

It's ironic that the argument against private/package being virtual is because
of performance reasons when we've already made the mistake of making all
methods virtual by default. I *still* can't get used to the fact that a public
method is virtual by default, it really lacks that documentation aspect of
having a 'virtual' keyword right next to it. 

And as argumented before, you could easily forget to mark something as 'final'
in a library, the user overriding such a method, followed by an API update
where you do a bugfix and mark it as final, which ends up breaking the user
code. Unfortunately this also becomes an argument against making
private/package virtual by default too.

Non-virtual by default + a virtual keyword + no limits on virtuality based on
access specifiers => dream come true (for me).

We're in an odd status-quo, all I can do is sigh at the situation.

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