4 ms·
That makes sense with regards to the runtimes and non-spec'd libs. But I was under the impression .NET Standard was essentially the class library spec and if .N
by kodablah 8y ago
That makes sense with regards to the runtimes and non-spec'd libs. But I was under the impression .NET Standard was essentially the class library spec and if .NET Core is/becomes the only impl of that class library spec it would seem strange to separate the spec from the impl when only one of each exists built by the same blessed implementer. I can definitely understand different compilers, AOT/JIT engines, GCs, etc. Even with minor .NET Standard impl differences in Mono, if they are so minor that they only augment .NET Core, it comes off as an optimization rather than a separate implementation. If the class library impl differences remain major, I would wonder why as surely, even when optimizing for portability vs performance, there is a lot of potential reuse.
- oaiey 8y agoConsider e.g. the cryptography support in the .NET Standard. On Linux it is based on OpenSSL (AFAIR), on Windows based on the crypto library there, on MacOS on another one, on Android another one and let us not speak of iOS. All of them follow on the surface the same API spec. But behind the scenes all .NET implementations have different strategies to deal with. And for good reasons. In this cases you need a standard but not a shared implementation.
- kodablah 8y agoI don't think deferring by platform preference is enough of a reason to separate the standard from the abstracting implementation. Most languages, with or without a "standard" and multiple implementations, defer to the platforms' preferred ways of, say, obtaining cryptographically random numbers.