Public classes have been changed to Sealed

[ghost]

Just like to understand the rationale behind this change, introduced by commit e276fbd. In this commit, some of the core caches like SourceCache have been changed to sealed. I could easily have misunderstood the full issue, but it doesn't seem like that was a necessary addition.

Is there there any benefit in making these sealed? From a package maintainers perspective, is that a concern? Being able to extend these is incredibly useful from my perspective. Rightly or wrongly, our code base currently extends SourceCache to provide several caches that expose the base cache functionality of SourceCache, alongside some additional methods to make cache use easier. It also allows a strong-named object, which has benefits in our particular application.

I'm also not against this being done, but it feels like it was outside the scope of the commit, and a breaking change that at the very least should be mentioned in the release notes.

[glennawatson]

#505

It was always intended to be sealed along with SourceList which has been for years. The oversight was corrected.

In terms of release notes you are probably correct, a separate PR would have made it more explicit for users and have it documented in the release notes. Bear in mind this is essentially the work of 1 or 2 people, not a large corporate machine producing release notes.

[ghost]

Certainly appreciate that; and noted re that issue, hadn't seen that one sorry. Only skimmed the open ones.