VSadov/Satori
1
0
Fork 0
mirror of https://github.com/VSadov/Satori.git synced 2025-06-10 18:11:04 +09:00
Code Activity

Address review feedback

Browse source 
Commit migrated from 65dbd33662
This commit is contained in:
Immo Landwerth 2016-01-19 14:46:08 -08:00
parent a8eec8d618
commit 4433757c02
2 changed files with 3 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

4
docs/libraries/project-docs/porting.md
View file

@ -6,7 +6,7 @@ The purpose of this document is to share the plans on how we're going to port mo
Compared to other .NET stacks, specifically the .NET Framework, Mono, Unity, and Xamarin the .NET Core platform doesn't expose enough APIs. This makes porting assets to .NET Core quite challenging, especially for areas which don't have replacements.
So we want to bring more API to .NET Core. In order to keep our promise of being open and transparent, we want to:
So we want to bring more APIs to .NET Core. In order to keep our promise of being open and transparent, we want to:
* Clearly communicate what we plan on porting, how we prioritize, what we don't want to port, and how we're thinking of cross-platform and compatibility.
* Avoid being the bottleneck by allowing community members to help with porting.
@ -64,8 +64,8 @@ Here are the high level guidelines:
- **Do not** expose Windows-only technologies in otherwise fully portable assemblies.
- **Do** factor large chunks of functionality that cannot be supported everywhere into their own assemblies.
- **Do** consider using tester-doer patterns if only a very small number of APIs cannot be supported in all environments.
* **Avoid** making changes that result in loss of binary and/or source compatibility between the .NET Framework and .NET Core.
* **Consider** using extension methods and partial facades to accelerate bringing revised APIs to the .NET Framework.
* **Avoid** making changes that result in loss of binary and/or source compatibility between the .NET Framework and .NET Core.
* **Avoid** "franken-designs" with extension methods and partial facades purely for the sake of .NET Framework compatibility.
## Unsupported Technologies

2
docs/libraries/project-docs/rtm.md
View file

@ -24,7 +24,7 @@ Unfortunately, when we introduced `TypeInfo` we also tried to clean up the surfa
Based on extensive customer feedback we decided that we need to improve reflection so that porting code to .NET Core becomes easier. The current proposal is to:
1. Keep the split, i.e. don't add those APIs to `System.Type`
2. Add all the APIs that used to live on `System.Type` and add them to `System.Reflection.TypeInfo`
2. Add all the APIs that used to live on `System.Type` to `System.Reflection.TypeInfo`
While having any delta is unfortunate, we believe it is vital to be able to deliver a .NET stack that doesn't require reflection, especially for ahead-of-time (AOT) compilation scenarios, in order to reduce footprint.