C# has static binding by default. Meaning methods aren't overrideable unless you specifically tag them as virtual. I love how in java you can take someone else's random class and override everything with some additional or alternate behaviour.

I think the tempering of that is good java programmers tend to final all the things. Methods for performance, fields for and getter setters for immutability. That's why Anders made the decision all those years ago to make non-virtual the default.

https://artima.com/intv/...

Java is a special snowflake...

I think that explicit is always better than implicit. Reason why I'm annoyed at the constant movement to save a few keystrokes by making things implicit (removing unnecessary keywords eg ;) ).

That is a good thing what do you mean :|

Ok so I am of the opinion that when you provide a qualified person with tools you should let them proverbially shoot themselves in the foot with them.

I feel that java programmers who final all their things are arrogant. They're saying "I considered every possible use case there is no need for you to modify my perfect class" or "You are not worthy to touch my perfect class. You simply cannot grasp its complexity."

Don't try to predict how people will use your stuff. Don't try to protect your fellow programmers from themselves. Some of them will make a mess. Some people's code might break when you change your class. That is ok and it's not your fault no matter how many morons say it is. Do not make your tools lesser for the sake of morons.

Imagine if someone was selling tractors to farmers and preventing them from being modified or repaired because someone might hurt themselves if they open the hood. Oh wait, that's already happening and it's bullshit. Don't be like John Deere.

@M3m35terJ05h OK. I'll bite.

What... Prevents you from removing the final flag if you need it?

@IntrusionCM Access to the source code. I'm talking about libraries. And sure most popular libraries are open source so I could just grab that, add it my project and change it as needed... but it's a bit of a hassle innit.

If it's in the same project I'm working in then yeah I can just change it. And I might not even need to subclass in the first place because it might be appropriate to change the class directly.

@M3m35terJ05h

Why is modifying a library by overriding it a good idea...

Cause I think it's bad. Really really really bad.

I feared such a reasoning would come up. :(

@IntrusionCM So don't do it then. I'll make my own risk assessment.

A trivial example is for logging for auditing purposes. You might want to override methods on a particular class and add log statements before calling super. Or maybe you want to fire some events. Subclassing is a lot easier than modifying every call. But no, I can't do that because someone somewhere might do something stupid. I say let em.

@M3m35terJ05h that someone somewhere is you mate

@M3m35terJ05h
What about wrapping the class to add logging?

@hbr147 It can be lot of boilerplate and refactoring. And it won't work if I need to pass it back to the library it came from.

@M3m35terJ05h
Tools aren't a prime intellect; they don't have the ability to infer intent or order. Even if you code defensively, making everything method virtual dramatically increases the risk of breaking changes to downstream consumers.

Given that, I tend to find the arrogance/overconfidence to be the assumption that your class is so robust that it will guarantee future robustness and consistency regardless of what users override on it.

Re: Hejlsberg, since it's the same appeal to pragmatism I'd make

"When we make something virtual in a platform, we're making an awful lot of promises about how it evolves in the future. For a non-virtual method, we promise that when you call this method, x and y will happen. When we publish a virtual method in an API, we not only promise that when you call this method, x and y will happen. We also promise that when you override this method, we will call it in this particular sequence with regard to these other ones and the state will be in this and that invariant.

Every time you say virtual in an API, you are creating a call back hook. As an OS or API framework designer, you've got to be real careful about that. You don't want users overriding and hooking at any arbitrary point in an API, because you cannot necessarily make those promises. And people may not fully understand the promises they are making when they make something virtual."

@SortOfTested

So all of this talk about making promises when you make things virtual is true - in C#. Because it's designed that way. Because it's not the default. If I flip that on I am broadcasting to everyone that I support anything they can do by overriding my methods. I suppose it's trending that way in java too with all this finality.

But that's not how I think it should be. Just because I'm not preventing you from doing something doesn't mean I'm pledging to support it. If I haven't documented use cases for overriding a method I don't support them. If it works, great. But it's your responsibility. If you're not ok with that, don't override. I'm not going to stop you though. You can make your own decisions.

Look at python - no privates. All you can do is say loud and clear "touch this at your own risk" and that's the way it should be. But I don't make everything public in C# because when you make something public in C# you're promising to support code that touches it.