dotnet/runtime

ReadOnlyObservableCollection.CollectionChanged should be made public

Open

#14 267 ouverte le 20 févr. 2015

Voir sur GitHub
 (14 commentaires) (13 réactions) (0 assignés)C# (5 445 forks)batch import
api-needs-workarea-System.Collectionshelp wantedwishlist

Métriques du dépôt

Stars
 (17 886 stars)
Métriques de merge PR
 (Merge moyen 12j 11h) (661 PRs mergées en 30 j)

Description

The ReadOnlyObservableCollection.CollectionChanged event is protected, which is flawed, it prevents you from being able to observe changes to it without casting to INotifyCollectionChanged.

I suspect the original thinking was because the collection is "read-only" it never changes - this is not correct. Read-only in .NET means that the consumer has a read-only view over a collection (which is why we project IReadOnlyList<T> to IVectorView<T>), not that the contents are immutable and never change.

While we've made protected members public in the past (such as Exception.HResult), this event was marked virtual, which while binary compatible, would be a source-breaking change for those that overrode it. I suspect very little have overridden it, but we may want to consider adding a new event with a different name such as Changed.

Guide contributeur

Direction de recherche
Le problème demande de rendre ReadOnlyObservableCollection.CollectionChanged public. Le principal défi est de maintenir la rétrocompatibilité, car l'événement est actuellement protégé et virtuel. Les approches possibles incluent le rendre directement public (avec un risque de changement cassant au niveau du code source) ou ajouter un nouvel événement public comme 'Changed'. La discussion inclut des préoccupations concernant la compatibilité binaire par rapport à la compatibilité du code source. Pour avancer, examinez les commentaires existants pour obtenir un consensus sur l'approche, étudiez la classe ReadOnlyObservableCollection dans le dépôt runtime (probablement dans src/libraries/...), et proposez une solution qui minimise les changements cassants.
Stack technique
csharp
Domaine
api
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
2
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-3 heures
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
C#
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
75