Updated C# and .NET docs supplement (markdown)

James Groom 2023-02-08 03:40:25 +10:00
parent f60887fc2a
commit b3fee40ced
1 changed files with 25 additions and 3 deletions

@ -1,9 +1,31 @@
To save us repeating our complaints about the lack of proper documentation under each section, let's agree to gather all the frustration here: To save us repeating our complaints about the lack of proper documentation under each section, let's agree to gather all the frustration here:
> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA > AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
### `System.Drawing.SystemIcons` rendered ## Collection type names
`IReadOnly{Collection,Dictionary,List,Set}` are for getting read-only views of the collections that implement them. They do not mean the collection is immutable (there are separate classes for that).
> Kotlin got this right by calling its interfaces e.g. `List`/`MutableList` instead of `IReadOnlyList`/`IList`. (And it also fixed the inheritance hierarchy.)
## Featureset is determined by language level AND target
see [feature matrix](https://github.com/TASEmulators/BizHawk/wiki/Available-C%23-and-.NET-features) page
## `System.Drawing.SystemIcons` rendered
[Docs for `SystemIcons`](https://learn.microsoft.com/en-us/dotnet/api/system.drawing.systemicons?view=netframework-4.8) don't include any pictures, so here they are (Win10, Mono 6.12.x): [Docs for `SystemIcons`](https://learn.microsoft.com/en-us/dotnet/api/system.drawing.systemicons?view=netframework-4.8) don't include any pictures, so here they are (Win10, Mono 6.12.x):
TODO ![SystemIcons_Win10](https://user-images.githubusercontent.com/13409956/217321727-b3527c87-3ad9-44bb-8276-01afde65a939.png)
![SystemIcons_Mono](https://user-images.githubusercontent.com/13409956/217311223-0d6acd76-203b-4694-9f45-4e4b8acc184b.png) ![SystemIcons_Mono](https://user-images.githubusercontent.com/13409956/217311223-0d6acd76-203b-4694-9f45-4e4b8acc184b.png)
## Type casting
There are two types of casts in C#: the C-style `(T) o` throws if the object is not of the desired type; whereas `o as T` evaluates to `null` if it's not of the desired type. There's no '?' in this `null`-producing operator. (This is probably only confusing if you use Kotlin.)
If an object being the wrong type is *exceptional*, throw an *exception* straight away. Having it reported as an NRE when there's no `null` in sight just delays debugging the problem.
## Type constraints (`where` clauses)
`class` in `where` clauses does not mean "not abstract", it means "reference type". Similarly, `struct` means "value type". There's a lot of complexity re: nullability, so [check the docs](https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/generics/constraints-on-type-parameters) if you're writing a generic method.
TODO euler diagram