3 ms·

But .NET definitely struggled with cultural issues around making APIs virtual. Because of Microsoft's strong 'no breaking changes' rule they were extremely caut

But .NET definitely struggled with cultural issues around making APIs virtual. Because of Microsoft's strong 'no breaking changes' rule they were extremely cautious about adding virtuals- in my experience it was not unusual to see it costed at 1 week dev/test time for a single virtual on an existing method (in WPF). C++ is also non-virtual by default and I think it's worked out OK.

derekdb 11y ago
Some of the cultural issues around avoiding virtual came from hard lessons with v1.0. After shipping v1 they realized that there were a large set of security and compatibility issues with not having framework classes sealed. No-one I worked with really like the idea of sealing all our classes, but the alternative was an insane amount of work. It is just too hard to hide implementation details from subclasses. If you don't hide the details then you can never change the implementation. I can't say for swift, but there were also real security challenges. It is hard enough to build a secure library, but to also have to guard against malicious subclasses is enough to make even the most customer friendly dev run screaming. My team hit this and it cost us a huge amount of extra work that meant fewer features. vNext we shipped sealed classes and more features and the customers were happier.