On 10 April 2013 23:15, Andrej Mitrovic <andrej.mitrov...@gmail.com> wrote:
> On 4/10/13, Manu <turkey...@gmail.com> wrote: > > The _problem_ is that functions are virtual by default. > > It's a trivial problem to solve, however it's a major breaking change, so > > it will never happen. > > I wouldn't say never. > ... don't get my hopes up! In fact, it might go hand-in-hand with changing how protection > attributes affect virtuality (currently they do, I'd argue they > shouldn't) > > For example one argument against allowing private and package methods > the ability to be virtual is performance, namely these methods are now > non-virtual and would suddenly become virtual if we allowed > private/package overrides (because users typically don't mark > private/package methods as final). > > However if we at the same time introduced a virtual keyword, then the > private/package methods would remain non-virtual. > > What would break are public methods which are overriden but don't use > the virtual keyword. So it's a breaking change but at least you won't > get any performance degradation by accident. > Rather, you'll gain innumerably, thanks to every property/accessor now being non-virtual as it should be. You make a compelling argument, although I'm easily sold on sich matters! It could be staggered in over a few releases... ie, in one release, 'virtual' is introduced - does nothing - encouraged to update code, next release, complain that missing virtual is deprecated, next release, turn it on proper; compile errors... Walter would have a meltdown I think :P Another reason I like the idea of a virtual keyword is that it > documents the method better. The user of a library would clearly see a > method can be overriden because it's marked as virtual, rather than > having to guess whether the method was left non-final on purpose or by > accident (accidents like that can happen..). > Hmm, this sounds familiar... where have I heard that before? ;)