Consider some sort of way to have psuedo-explicit abstract class implementations #3445
Replies: 8 comments
-
This looks like a scenario that would be satisfied by covariant return types: |
Beta Was this translation helpful? Give feedback.
-
It isn't
Boxing is not an identity conversion |
Beta Was this translation helpful? Give feedback.
-
A very similar proposal: #1618. |
Beta Was this translation helpful? Give feedback.
-
Good point, I missed that The CLR does support the concept of explicit overrides. As long as the signatures match the overriding method can have any name or accessibility. |
Beta Was this translation helpful? Give feedback.
-
Nice thing, but not obvious, how to derived class can override // This is why I prefer "non-virtual interface" design. |
Beta Was this translation helpful? Give feedback.
-
Couldn't you just make a "ValueRent"` method? |
Beta Was this translation helpful? Give feedback.
-
Yes, and that is my current solution. But it's not very nice @wrkettlitz , as it doesn't make it immediately clear what the purpose is |
Beta Was this translation helpful? Give feedback.
-
You can try something like this: public abstract class CustomAllocator<T, TMemoryOwner> : MemoryPool<T> where TMemoryOwner : IMemoryOwner<T>
{
protected abstract TMemoryOwner RentCore(int minBufferSize = -1);
public sealed override IMemoryOwner<T> Rent(int minBufferSize = -1) => RentCore(minBufferSize);
}
public class FrameAllocator<T> : CustomAllocator<T, FrameAllocator<T>.Frame>
{
public struct Frame : IMemoryOwner<T>
{
// ...
}
protected override Frame RentCore(int minBufferSize = -1) => Rent(minBufferSize);
public new Frame Rent(int minBufferSize = -1) => new Frame();
} |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The idea is just being able to use an explicit interface style implementation on abstract classes. E.g
This would allow boxing to be avoided when calling exact types
Beta Was this translation helpful? Give feedback.
All reactions