21–30 of 78 posts
> Mark classes as sealed by default Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
Makes me wonder: Can you add extension methods to sealed classes?
> Mark classes as sealed by default Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
It is a general design principle for .net libraries that you should seal a class unless you deliberately and carefully design it to be extensible. If a class is unsealed you are basically not able to change it ever again, since someone might have subclassed it and depend on all kinds of internal behavior. So it should only be done very deliberately.
Is it? A more typical approach, IMO, is for internal classes to be marked as `internal`, and for `public` classes to be considered part of the public API.
> Mark classes as sealed by default Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
Or, reflection if you're breaking the rules anyway.
One of the tips is to avoid Linq, which many .NET developers are hesitant to do. I made a library that lets you use Linq style convenience functions without a performance hit in many cases: https://github.com/jackmott/LinqFaster
Focused on reducing the allocations which makes linq heavy
> JIT won't inline functions that throw Seriously? Never had to worry about that in Java land. What would be the reason for this?
One of the tips is to avoid Linq, which many .NET developers are hesitant to do. I made a library that lets you use Linq style convenience functions without a performance hit in many cases: https://github.com/jackmott/LinqFaster
Given the immediate next bullet point in the article is about foreach operations over List, that would be my top expectation why they were seeing so much allocation in Linq. ToList() allocates a lot, and to many projects I've seen reify everything with ToList() way too often in Linq usage. I've argued before that List is very rarely the appropriate data structure for a lot of Linq work, and personally consider ToList() harmful. A successful strategy I've used to cleaning up Linq performance in projects is to simply start by remove all ToList() calls entirely and work to move API signatures to use smarter, more appropriate data types than List and IList everywhere.
Earlier quoted context omitted.
Why doesn't the JIT assume classes are effectively sealed until it sees a subclass, like the JVM does.
Because it is bad design known as fragile base class, which usually leads to hard to track down bugs, because someone somewhere is accessing methods or internal class data structures that they shouldn't have to in first place.
You're talking about the programming model, where I'm talking about the implementation.
> Mark classes as sealed by default Please, no! This shouldn't be the default - it's a constant bugbear of mine where I want to extend a class from a library, and I can't because it's been sealed for no good reason.
Why doesn't the JIT assume classes are effectively sealed until it sees a subclass, like the JVM does.
It would be nice if .NET Core profiling was a bit easier on Linux, Microsoft has a shell script[1] to do profiling but it requires Windows only tools. They don't ship Crossgen with the Linux packages, and you have to manually generate the .NET runtime symbols. I've gotten things like FlameGraphs working using BCC profile[2], but it took quite a bit of work. [1]: https://raw.githubusercontent.com/dotnet/corefx-tools/m…