http://d.puremagic.com/issues/show_bug.cgi?id=3258
--- Comment #9 from Andrej Mitrovic <andrej.mitrov...@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: -------