Funkcje C # lub .Net do odcięcia przy założeniu, że nie jest wymagana kompatybilność wsteczna? [Zamknięte]

Ewoluuje każdy produkt lub struktura. Przede wszystkim ma to na celu zaspokojenie potrzeb użytkowników, wykorzystanie nowych mocy obliczeniowych i po prostu ulepszenie. Czasami główny cel projektu zmienia się również wraz z produktem. Framework C # lub .net nie jest wyjątkiem. Jak widzimy, obecna 4. wersja różni się znacznie od pierwszej. Ale rzecz stanowi barierę dla tej ewolucji - wstecznej kompatybilności.

W większości frameworków / produktów niektóre funkcje zostałyby odcięte, gdyby nie było potrzeby obsługi kompatybilności wstecznej. Według ciebie, jakie są te funkcje w C # /. Net?

Podaj jedną funkcję na odpowiedź.

Anonimowe metody . Myślę, że wszyscy zgadzają się, że anonimowa składnia metody wybrana dla C # 2.0 jest masywna i niezgrabna w porównaniu do składni lambda dodanej do C # 3.0. Bardzo niefortunnie jest mieć dwie prawie identyczne składnie, aby zrobić to samo.

Pozbyłbym się zbiorów innych niż ogólne. Są obrzydliwością ... i jest zbyt wiele przypadków, w których używam linq i muszę coś zrobić

var customObjects = container.CustomObjects.Cast<CustomObject>();

Za każdym razem, gdy muszę to robić, umiera niewielka część mojej duszy.

nieważne jako typ . Dlaczego, u licha, „pustka” jest typem? Nie ma instancji, nie ma wartości, nie można go używać jako argumentu typu ogólnego, typu parametru formalnego, typu lokalnego, typu pola lub typu właściwości. Nie ma znaczenia jako typ; jest raczej faktem na temat wpływu wywołania metody na stos maszyny wirtualnej. Ale maszyna wirtualna to po prostu: maszyna wirtualna. Prawdziwa maszyna umieści zwracaną wartość w rejestrze (zazwyczaj EAX na x86) i nie wpłynie w ogóle na stos! Pustka jako typ to po prostu zły pomysł dookoła.

Gorzej: gdy jest używany jako typ wskaźnika, ponieważ w void*nim oznacza coś zupełnie innego niż to, co oznacza, gdy jest używany jako typ zwracany. Teraz oznacza „wskaźnik do miejsca przechowywania nieznanego typu”, co nie ma nic wspólnego z jego znaczeniem jako „metoda, która nie zwraca żadnej wartości”.

Możemy wymienić void* jako typ wskaźnika na IntPtr. (I void**z IntPtr*i tak dalej.) Możemy zastąpić void jako typ zwracany przez „Unit”, typ, który ma jedną wartość, a mianowicie null. Implementacja CLR mogłaby następnie zdecydować, że wywołanie funkcji typowanej dla jednostki może odpowiednio zoptymalizować wykorzystanie rejestrów lub stosów, wiedząc, że zwracane wartości null można bezpiecznie zignorować.

W takim świecie nie potrzebujesz już oddzielnych Func<A, R>i Action<T>delegatów. Action<T>jest po prostu Func<T, Unit>.

Puste oświadczenie; . Podatny na błędy, prawie zawsze literówka, i nie daje żadnego dodatkowego znaczenia, które nie zostało jeszcze wyrażone przez {}.

Niebezpieczna kowariancja dla tablic typu referencyjnego . Przy włączonej kowariancji typu IEnumerable<T>, przynajmniej część potrzeby kowariancji macierzowej zniknęła. (Gdybyśmy mieli kowariantny interfejs listy tylko do odczytu, to nie potrzebowalibyśmy go wcale).

Jednoargumentowy operator plus . Najmniej użyteczny operator wszechczasów. Gdybyśmy nie musieli go trzymać dla kompatybilności wstecznej, wyjąłbym to w mgnieniu oka. Kto z tego korzysta, ktoś?

(Wyjaśnienie: Operator jednoargumentowy plus +xnie jest operatorem wstępnego zwiększania ++x, nie jest operatorem wstępnego zwiększania x++i nie jest operatorem dodawania binarnego x+y.)

Domyślne literały liczbowe to double

W przypadku większości aplikacji biznesowychdecimal jest to bardziej odpowiednie ... a może lepiej byłoby po prostu usunąć ideę domyślnej i zmusić programistę do dokonania wyboru.

(To „usuń domyślne” byłoby również odpowiednie dla niektórych innych rzeczy. Na przykład zrezygnowałem z prób przekonania wszystkich, że klasy powinny być domyślnie zapieczętowane, ale podejrzewam, że łatwiej jest przekonać ludzi, że powinni o tym pomyśleć czy ich nowa klasa powinna być zapieczętowana, czy też nie, i wyraź to).

Jest to raczej wskazówka niż funkcja, ale myślę, że jest ważna, ponieważ jest już zbyt głęboko zakorzeniona w ludzkich umysłach jako kanoniczne i najlepsze rozwiązanie:

Oficjalny wzór do wdrożenia IDisposable.

Jest to uciążliwe i istnieją lepsze sposoby .

Ja wiem, istnieją duże różnice między poszczególnymi klasami timera. Ale czy w ogóle nie moglibyśmy się ich pozbyć?

Metody i typów Arrayi List<T>które stały się przestarzałe wraz z Linq, na przykład:

• Array.TrueForAll można zastąpić Enumerable.All
• Array.FindAll można zastąpić Enumerable.Where
• List<T>.ConvertAll można zastąpić Enumerable.Select
• Predicate<T> można zastąpić Func<T, bool>
• Converter<T,R> można zastąpić Func<T, R>
• IComparer<T> naprawdę powinien być delegatem Func<T, T, int>

Nieogólni delegaci Podobnie jak nieogólne kolekcje, nieogólni delegaci są bezużyteczni teraz, gdy mamy serię Func i Action. I odciąłbym warianty przy trzech parametrach. Jeśli masz więcej niż trzy parametry, utwórz strukturę i użyj tego jako pojedynczego parametru. Zadeklarowanie konkretnego delegata do obsługi zdarzeń nie jest zbyt OSADNE.

Usługi sieciowe asmx

Myślę, że obecnie są dość przestarzałe w WCF.

Winforms
Byłoby miło nie musieć nawigować między dwiema platformami stacjonarnymi. WPF to miejsce, w którym wszystko się dzieje, więc frustrujące jest posiadanie pełnej nadmiarowości na poziomie platformy.