[Proposal] Allow overriding for all .NET's classes

[Xyncgas]

Motivation :
We can't change the internal implementation of types provided in the .NET library (for example System.Random) without reimplementing it ourselves or forking .NET

Libido :
Let me change implementations, even if they are sealed, even if members are protected, I should be able to see it, to change members of classes, as if I am directly modifying its source, without actually seeing the source, as if private/protected/public...(visibility) keywords don't matter, as long they are included in .NET System namespace I should be able to do whatever I want without needing to know about its source code / its implementation

[danmoseley]

You're asking for API that allows you to change method bodies? Would this be at runtime or compile time?

[Xyncgas]

Not changing method bodies, but overriding the implementation of any .NET classes in the System namespace, for example changing Stack to use linked list.
One way to achieve it is obviously just reimplement Stack, but I don't want to do that
So another way to do it would be marking everything as public virtual

[danmoseley]

I cannot imagine supporting such a mechanism, for a myriad of reasons not least cost, supportability, and value. You can create your own Stack type and use it.

[huoyaoyuan]

An example is Collection<T> vs List<T>. There functionalities are very similar. Collection<T> serves as a base class, so there're virtual members. List<T> serves for performance, so there is nothing virtual.

Virtual member does cost a lot. Meanwhile, making virtual to non virtual is breaking.

[Clockwork-Muse]

List isn't a subclass of Collection, it implements the interface ICollection.

[Joe4evr]

@Clockwork-Muse That's not what Huo said, tho. It's worded a bit clunky, but "Collection<T> serves as a base class [for custom collections]" is completely accurate.

Meanwhile, making virtual to non virtual is breaking.

Fun fact, making a non-virtual member virtual is also binary breaking since the introduction of ?.. 🙃

[Rekkonnect]

all .NET classes

That's very bold a statement. System.Random is a great example of being unsealed, but that doesn't mean all of .NET should be.

That being said, it's a good idea to revisit sealed APIs and consider unsealing them.

[stephentoub]

That being said, it's a good idea to revisit sealed APIs and consider unsealing them.

Unsealed classes have a very real cost as well, both in terms of our ability to evolve them and in terms of raw perf. We would need a really good reason to unseal a currently sealed type.

[Clockwork-Muse]

System.Random is a great example of a type that wasn't properly designed to be overriden, and causes issues with some of the attempts to update/modernize it.

[Xyncgas]

I admit all I had to do was to look up System.Random's source code and modify it.
It comes with the down side that, if System.Random had a bug in .NET 6 and they found out in .NET 7 and fixed it, I might not get notified or get it fixed in my own implementation immediately.
Meanwhile I am tempted to desire a way to 'fork' any .NET implementations to use it as my own to essentially have version control like we do with source code but : Directly in the source code (for example, overriding virtual methods)

[Clockwork-Muse]

@Xyncgas - If you're messing with internals, you're on your own, and manually tracking the versions and changes is the expected and normal path.
You'd be operating outside of the normal design and API guarantees; messing with the internals, you're not guaranteed that anything is still the same, or that your changes would work. You run into the same problem even if you do something like replace the class/methods at runtime via reflection or other hackery (you don't need to fork the runtime itself) - suddenly things you expected to work the same just won't.

[deeprobin]

The use of sealed classes are more performant (call is in most cases faster than callvirt). If you really want to change the behavior of these classes why don't you just create a wrapper type around them?

https://stackoverflow.com/a/3849957/7600021
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/#peanut-butter

[Rekkonnect]

If you really want to change the behavior of these classes why don't you just create a wrapper type around them?

That solution is obvious and works, but there is a reason inheritance is a thing, and widely adopted in the ecosystem. Composition works for patching problems like that, this issue addresses the concern over patching it on the BCL itself.

I have written an AdvancedRandom class that wraps the Random class, but I still went through the typical problems:

• induced overhead with an extra allocation (one for the Random object, one for the wrapping object)
• re-writing the definitions of all the exposed methods, which call the wrapped object's methods

In better words, not fun. It works, but it's not something I would rather have to deal with for the rest of my life. And if Random cannot get changed on its own, a new Random class can be created and be advised to use it over the standard one, for us consumers to take better advantage of.

[deeprobin]

Random is not sealed at all and can be changed.
For ref:

runtime/src/libraries/System.Private.CoreLib/src/System/Random.cs

Line 13 in c6829b9

public partial class Random

However, I do not understand the problem in principle. If you don't like something about .NET then create your own fork or if it's a bug that's just not in the pipeline then feel free to create a PR.

[deeprobin]

Alternatively, you can write a SourceGenerator that replaces your uses of Random with AdvancedRandom.

And the more secure alternative to Random does also not inherit from Random: https://docs.microsoft.com/de-de/dotnet/api/system.security.cryptography.randomnumbergenerator?view=net-6.0

[Clockwork-Muse]

... the problem @alfasgd has is the writing of AdvancedRandom in the first place, so a source generator isn't less work.

That aside...

induced overhead with an extra allocation (one for the Random object, one for the wrapping object)

Random is a poor example for this point, because you're usually only going to have one instance for your entire application; the extra allocation will not be noticeable. Most of the other cases where you might believe you need to wrap such classes are going to be similar - there's only going to be one or a few instances of them.