-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do something with IReadOnlyCollection and ICollection. We needs good abstractions hierarchy. #219
Comments
I like this except that so many .NET libraries, not just the BCL, have accepted that IReadOnly == IReadable and follow that convention. I don't see any wins in fixing it in the BCL after it's sunk in and spread so far. I choose ReadOnly over Readable because that's what it means to everyone now and it communicates precisely what I intend. Yes it's illogical but like the English language, we have no problem making ourselves understood. |
If we can't do anything in CLR, We can use not-null reference approach. ICollection annotated with ImmutableAttribute or ReadableAttribute should be handled by compiler and DevTools to block from writing to a collection. public void SomeReadOnlyConsumer(IReadable<T> c){} or public void SomeReadOnlyConsumer(readable ICollection<T> c){} can be treated by CLR as public void SomeReadOnlyConsumer([Readable]ICollection<T> c){} This approach even better fits to immutability semantic. IFreezable is best example. The same ICollection can be mutable and immutable after Freeze call. So it' very very close to well-designed nullability solution. Toolset will save us! |
IReadOnly == IReadable, Yes i agree it's not a bit trouble. We just needs IImmutable and some way to annotate semantic of each variable/argument/field/property. |
Yes I will duplicate. But I disagree without that nothing to do with C#. Non-Null reference is also "too late" feature. But it will be finally appear in C# 8.0. public void MyMethod(readable ICollection<T> c)
where T: new
{
c.Add(new T()) // Compiller Error/Warning.
} It's toolset/C# languate related solution method. |
public void MyMethod(readable ICollection<T> c)
where T: new
{
c.Add(new T()) // Compiller Error/Warning.
}
public void MyMethod(immutable ICollection<T> c)
where T: new
{
c.Add(new T()) // Compiller Error/Warning.
} This would be killing feature, that can greatly improve compile-time checking. |
public class MyClass
{
// here why readable but not readonly keyword.
private readable readonly ISet<strings> _myStrings;
public MyClass(IEnumerable<string> strings)
{
_myStrings = new HashSet<string>(strings);
}
public readable ISet<string> MyStrings {} => _myStrings;
}
public void Test()
{
var a = new MyClass(new[] {"dog", "cat"});
a.Contains("dog"); // Good usage.
a.MyStrings.Add("mouse"); // Compiler error/warning.
} |
There is more suitable solution for this general problem: So I am closing this issue on C# Language repository. |
Not sure if you've arrived at a similar idea independently, or if you were inspired by it, but the approach of marking variables as |
Thank you for this link, I will inspect their work and result. |
Just drop IReadOnly****, mark them obsolete.
We can't do anything with backward compatibility here.
If we inherit ICollection from IReadOnlyCollection we will broke existing code.
See: http://stackoverflow.com/questions/12622539/why-doesnt-generic-icollection-implement-ireadonlycollection-in-net-4-5
But may be sometime will be good point do do this breaking change, provide tools for migration automation.
And also IReadOnly*** is not clear solution, we needs IReadable*** and IImmutable****
This is not-null reference types like problem. But it's second after nullability.
Let's start/continue to solve this problem.
The text was updated successfully, but these errors were encountered: