search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.98k stars 4.66k forks source link

Explain the relationship between "contract" reference assembly and a platform implementation #15630

Closed davidfowl closed 4 years ago

davidfowl commented 8 years ago

I have a conversation on Twitter about the dotnet TFM and it's relationship to the other TFMs that already exists. The analogy that clicks with people is the abstract base class and implementation analogy and I don't think that is specifically called out anywhere in the doc (https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/standard-platform.md).

In general, we need to state the relationship between CoreFx defining contracts and APIs that other platforms implement as that resonates with people and things click for them.

In C# sharp

public abstract class DotNetStandard51
{
  ...
}

public abstract class NetFramework45 : DotNetStandard51
{
  ...
}

/cc @Petermarcu @richlander

robertmclaws commented 8 years ago

This explanation does not make sense either, as you cannot retroactively have a class that has already shipped in a binary implement a new abstract class, without breaking binary compatibility. You can't ret-con your way into explaining the solution with code that did not ship that way in the first place.

This also brings up the questions "What happened to .NET Standards 1-4, if we're not suddenly on Standard 5? What does Standard 5.X have to do with NetFramework50? Why does NetFramework50 implement DotNetStandard5.5? Why are versions shipped 6 years apart only separate by 3 point releases of the standard?

The solution makes sense UNTIL you guys start with this 5.x stuff. You are shipping v5 of .NET right now. This is V1 of the "generations" idea. Not V5.

davidfowl commented 8 years ago

This explanation does not make sense either, as you cannot retroactively have a class that has already shipped in a binary implement a new abstract class, without breaking binary compatibility. You can't ret-con your way into explaining the solution with code that did not ship that way in the first place.

I don't get what you're saying and I think you missed the point. It's an analogy to classes, these "contracts" are not really classes at all. The mental model is that the standard is a base class and platforms implement a standard.

This also brings up the questions "What happened to .NET Standards 1-4, if we're not suddenly on Standard 5? What does Standard 5.X have to do with NetFramework50? Why does NetFramework50 implement DotNetStandard5.5? Why are versions shipped 6 years apart only separate by 3 point releases of the standard?

Give the document a re-read. We started over from 1.0 because it was confusing.

The solution makes sense UNTIL you guys start with this 5.x stuff. You are shipping v5 of .NET right now. This is V1 of the "generations" idea. Not V5.

The original idea was to .NET Core 5.0 but naming is hard man :smile: