[nem-pl] Bugreporty do MS

[Kamil Skalski]

Hej!

Dodałem kilka bug reportów i sugestii na temat tego co zauważyliśmy
zepsutego w MS.NET frameworku.
MS ma teraz odpowiednik bugzilli:
http://lab.msdn.microsoft.com/productfeedback/default.aspx

Żeby bugi szybciej były przeglądane wymagają, żeby więcej ludzi zagłosowało,
że są ważne. Apel zatem (do developerów w sumie, ale każdy może się
przyłączyć), żeby założyli sobie konta w MS Passport / MSDN i co tam jeszcze
potrzebne i pogłosowali na bugi:

http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=77679c90-f821-49d7-8148-548741cba38c

http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=376f87ea-71b8-4fd4-9366-9b9672a1b99a

http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=60799788-f208-426c-92cf-311a7907989c

http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=f19bd1c1-0cc6-41fc-acad-4877498d65ca

Jak można zobaczyć pod ostatnim linkiem, exception rzucający się przy
uruchomieniu całkowicie poprawnego kodu został uznany za "by design", ale
nie powinniśmy się zrażać.

Druga sprawa, to żeby doprecyzować kolejne rzeczy, które możnaby zgłosić:
- Unable to emit nested value types (they need to be finalized after the
parent class but this is not always possible).
Wydaje mi się, że z tym można sobie spokojnie poradzić samemu (co w sumie
nie zmienia faktu, że ograniczenia na kolejność finalizowania typów w MS.NET
są mocno przesadzone). Wystarczy finalizować typy od zewnątrz. W jakich
sytuacjach jest to niemożliwe? Przecież tu się nie da zrobić cyklu, a jeśli
z jakiegoś powodu to się musi zawsze sypać, to proszę o przykład.

- Error messages could be improved by always giving full names of types
involved in erraneous situations.
 Możesz Michał doprecyzować? Mi przychodzi na myśl sytuacja
InvalidCastException, gdzie nie ma nic na temat jaki typ do jakiego został
zcastowany. Warto by jeszcze kilka przykładów zrobić, żeby było widać że to
ważne.

Kamil