On 3 June 2013 18:11, deadalnix <[email protected]> wrote: > On Monday, 3 June 2013 at 07:30:56 UTC, Kapps wrote: > >> On Monday, 3 June 2013 at 07:06:05 UTC, Manu wrote: >> >>> There are functions that >>> the author intended to be overridden, and functions that have no business >>> being overridden, that the author probably never imagined anyone would >>> override. >>> What if someone does come along and override one of these, and it was >>> never >>> designed to work under that circumstance in the first place? >>> At very least, it will have never been tested. That's not a very robust >>> API >>> offering if you ask me. >>> >> >> This is something just as important as the performance issues. Most of >> the time people will leave functions to simply use whatever the default is >> for virtual/final. If it's final, this works fairly well. The author hasn't >> put in the effort to decide how to handle people overriding their function. >> But with virtual by default, you don't know if the author actually >> considered that people will be overriding the function or if it's simply >> that they didn't bother specifying. I know the vast majority of my code is >> virtual, simply because I didn't specify the 'final' keyword 500 times, and >> didn't think about that I'd need to do it. The resulting code is unsafe >> because I didn't consider those functions actually being overridden. >> >> > The whole concept of OOP revolve around the fact that a given class and > users of the given class don't need to know about its subclasses (Liskov's > substitution principle). It is subclass's responsibility to decide what it > override or not, not the upper class to decide what is overriden by > subclasses. >
Then OOP is fundamentally unsafe, because the author will never consider all the possibilities! If you want to create a class with customizable parts, pass parameters to > the constructor. This isn't OOP what OOP is about. > Eh? The performance concern is only here because things has been smashed > together in a inconsequent way (as it is often done in D). In Java for > instance, only overriden function are actually virtual. Everything else is > finalized at link time. Java is not compiled. If you compile Java code, all functions are virtual always. It's impossible in D with separate compilation, and dynamic libraries seal the deal. > Which is great because you are able to override everything when testing to > create mock for instance, while keeping good performance when actually > running the application. > I'm not taking away your ability to make everything virtual, you can type 'virtual:' as much as you like.
