Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Nowości w C# 7 — jest kontrowersyjnie

Jakiś czas temu pisałem o nowościach jakie wprowadza finalna wersja C# 6. Wówczas zmiany można było przetestować w Visual Studio 2015 i spokojnie zacząć ich używać na co dzień na środowisku produkcyjnym.

Będąc na tegorocznym .NET DeveloperDays słynny Jon Skeet delikatnie musnął nowości w C# 7, pokazując Tuple i dekompozycję. Pomimo tego opinie o zmianach były dość podzielone (z przewagą tych negatywnych).

Sprawdźmy zatem całościowo jakie nowości szykują się w C# 7. Obecnie (gdy piszę te słowa) dostępne jest już testowe wydanie Visual Studio 15 (Preview 5), a także wraz z nim podglądowa wersja C# 7.

Wymagania

W celu przetestowania C# 7 potrzebujemy:
  • Visual Studio 15 - obecnie w wersji Preview 5
  • Dodanie do projektu paczki System.ValueTuple z NuGeta, jeśli chcemy "pobawić się" nowymi Tuplami

Pattern matching

Jednym z ciekawszych ficzerów w nowej odsłonie C# jest Pattern matching. Funkcjonalność ta daje name możliwość sprawdzenia warunku wartości, a następnie przetworzenie tej wartości, jeśli warunek jest prawdziwy. Patterns są nowymi elementami języka C#. W obecnej fazie do dyspozycji mamy następujące wzorce:

  • constant patterns: c - gdzie c jest wyrażeniem constant w C#, wzorzec testuje czy wejście jest równe wyrażeniu c
  • type patterns: T x - gdzie T jest typem, a x identyfikatorem, wzorzec sprawdza czy wejście jest typu T i jeśli tak jest wartość z wejścia podstawia pod nową zmienną x typu T
  • var patterns:var x - gdzie x jest nazwą nowej zmiennej, wzorzec (sprawdzenie jest zawsze prawdziwe) jedynie ustawia wartość z wejścia pod nową zmienną x o typie takim jak wejście

W tym momencie C# 7 rozszerza dwie konstrukcje języka o pattern matching: is a także case.

W przypadku is otrzymujemy możliwość umieszczenia wzorca po prawej stronie, zamiast typu, np.:

public void CheckPackageCode(object code) { if (code is null) return; if (!(code is string packageCode)) return; if (packageCode is "errorCode") return; Console.WriteLine($"correct code: {packageCode}"); }

Konstrukcja w case pozwala na więcej, a także przejrzystość kodu jest wówczas znacznie większa.

public void CheckData(Vehicle vehicle) { switch (vehicle) { case Tank t: t.Shot(); break; case Car c when c.DoorCount == 4: Console.WriteLine($"sedan with {c.DoorCount} doors"); break; case Motorbike b when b.IsHelmetAttached: Console.WriteLine($"motorbike ready to go!"); break; case null: Console.WriteLine("no vehicle!"); break; default: break; } }

Opinia

Ciekawa funkcjonalność, która nie od początku przypadnie do gustu wszystkim, ale zapewne z biegiem czasu zyska zwolenników. Ciekawi mnie, o jakie dodatkowe konstrukcje rozszerzy Microsoft zastosowanie pattern matching w finalnej wersji C# 7.

Tuples

Klasę Tuple wprowadzono w C# 4. Miała być ona alternatywą do tworzenia "prywatnych" dedykowanych klas w przypadku, gdy np. chcemy jednorazowo zwrócić kilka wartości z metody.

Wraz z C# 7 otrzymujemy typy tuple i literały tuple.

public (string, string, int) GetUserData(int id) { //load data from db return ("Zygmunt", "zygi", 123009); }

W ten sposób możemy zwrócić dane znacznie szybciej niż poprzez użycie klasy Tuple. Zwracane dane będą miały publiczne pola Item1, Item2, (...) podobnie jak miało to miejsce wcześniej:

var data = GetUserData(5); Console.WriteLine($"data : {data.Item1},{data.Item2},{data.Item3}");

Jednakże teraz nic nie stoi na przeszkodzie, aby ponazywać poszczególne pola:

public (string name, string login, int phone) GetUserData(int id) { //load data from db return ("Zygmunt", "zygi", 123009); }

lub jeszcze w inny sposób:

public (string, string, int) GetUserData(int id) { //load data from db return (name: "Zygmunt", login: "zygi", phone: 123009); }

wówczas w kodzie do poszczególnych pól odwołamy się poprzez nadane nazwy:

var data = GetUserData(5); Console.WriteLine($"data : {data.name},{data.login},{data.phone}");

Opinia

Przez wielu klasy Tuple do dziś są na cenzurowanym i nie bez przyczyny. Łatwo o zaciemnienie kodu właściwościowymi Item1, Item2,... . Kolejne wcielenie tupli nie przysporzy raczej olbrzymiej liczby zwolenników temu rozwiązaniu. Kod delikatnie zyska na czytelności poprzez aliasy, ale nadal obiekty będą posiadały prócz własnych nazw... pola Item1, Item2... Oprócz tego, że w oczy nie będzie kuła nazwa Tuple (wywołująca u niektórych słuszną alergię), nie zyskamy aż tak wiele. Faktem jednak jest, że aliasy pomogą w znacznie przyjemniejszej pracy z tuplami.

Deconstruction

Z Tuplami związana jest również nowa funkcjonalność - dekonstrukcja. Dzięki niej możemy obiekty Tuple (ale również i zwykłe klasy) rozdzielić na dedykowane zmienne. Przykład z punktu wyżej możemy rozbić zatem na różne sposoby:

(string name, string login, int phone) = GetUserData(5);

(var name, var login, var phone) = GetUserData(5);

var (name, login, phone) = GetUserData(5);

a nawet przypisać do istniejących zmiennych:

(name, login, phone) = GetUserData(5);

Dekonstrukcję można wykonać na tuplach, ale również na obiektach własnych klas. W tym celu należy do deklaracji klasy dodać metodę:

public void Deconstruct(out T1 x1, ..., out Tn xn) { ... }

Np.:

public class User { public string Name { get; set; } public string Login { get; set; } public int Phone { get; set; } public string Address { get; set; } public User(string name, string login, int phone) { Name = name; Login = login; Phone = phone; } public void Deconstruct(out string name, out string login, out int phone) { name = Name; login = Login; phone = Phone; } }

Wówczas mając obiekt

User u = new User("Zenek", "mis", 0800);

Możemy dokonać jego dekonstrukcji w trywialny sposób:

var (userName, userLogin, userPhone) = u;

Sugeruje się, że dekonstrukcja we własnych klasach będzie zapewne używana jako "odwrotność" konstruktora. Czas pokaże. Warto zauważyć, że dekonstruktor przyjmuję parametry wyjściowe i nie zwraca typu. Dzięki temu można przeciążyć dekonstruktor i mieć ich kilka w pojedynczej klasie.

Opinia

Przyznaję, że dekonstrukcja w formie w jakiej przedstawiono ją w C#7 zupełnie mnie nie przekonuje. O ile jeszcze razem z tuplami ma to jakiś sens (jeśli przełkniemy tuple jako takie), to w połączeniu z obiektami zwykłych klas jest to opcja delikatnie zbędna. Przeglądając taki kod nie do końca będziemy w stanie wiedzieli skąd takie zmienne się wzięły, co więcej, dużo będzie tu zależeć od nazw poszczególnych parametrów w dekompozycji. Dodajmy do tego jeszcze przeciążenie dekompozycji i interpretacja takiego kodu będzie już wyzwaniem. Nie wyobrażam sobie, aby używać tego ficzeru na co dzień, przy większych projektach. Czuję, że będzie to kolejny często "banowany" bajer w rozleglejszych rozwiązaniach, niczym starszy brat - klasa Tuple.

Out variables

C# 7 uprzyjemnia także pracę z parametrami przekazywanymi z modyfikatorem out. Do tej pory chcąc użyć metody z parametrami out, musieliśmy je wcześniej zadeklarować. Było to o tyle niewygodne, gdyż w większości przypadków zmienne te i tak były nadpisywane przez metody, do których były przekazywane.

int i; if (int.TryParse(s, out i)) { Console.WriteLine($"int : {i}"); }

Wraz z C# 7 mamy zatem możliwość zadeklarowania parametru outer w miejscu jego przekazania:

if (int.TryParse(s, out int i)) { Console.WriteLine($"int : {i}"); }

Z racji tego, że typ jest znany dla parametru outer, zamiast podawać konkretny typ, można użyć var:

if (int.TryParse(s, out var i)) { Console.WriteLine($"int : {i}"); }

Opinia

Out variables niezmiernie przypadł mi do gustu. Rozwiązanie to jest bardzo intuicyjne i naturalne, a jednocześnie zmniejsza ilość niepotrzebnego kodu, który często był generowany przy metodach z parametrami out. Mała rzecz, ale niezmiernie cieszy.

Local functions

Kolejna nowość to metody lokalne. Jest to nic innego jak możliwość deklarowania funkcji na potrzeby pojedynczej metody:

public string Multi(int dataId) { return $"Multiplied {MultiplyFn(2)} {MultiplyFn(3)}"; int MultiplyFn(int multi) { var tmp = dataId * multi; Console.WriteLine(tmp); return tmp; } }

Warto odnotować, że w funkcji lokalnej widoczne są zmienne z metody w której została ona zadeklarowana.

Opinia

Jest to dość kontrowersyjna opcja na dłuższą metę. Obawiam się, że dodawanie lokalnych funkcji w metodach może spowodować, że część kodu będzie dublowana. "Skoro nie ma czegoś co mam obliczyć, to zapewne nikt tego nie będzie używał" - takie przekonanie może doprowadzić do rozrostu lokalnych funkcji i bałaganu w kodzie. Dodatkowo jest to już jawne dawanie zielonego światła na wyrzucenie do kosza Single Responsibility Principle (SRP)...

Return values and local variables by reference

W C# 7 postawiono również na optymalizację. Jednym z tych przykładów jest możliwość deklarowania zmiennych po referencji i zwracania wartości poprzez referencję.

public ref Block GetDataWithRef(ref Block[] data, int index) => ref data[index]; public Block GetData(ref Block[] data, int index) => data[index]; public struct Block { public decimal DataBlock { get; set; } } public void TakeARide() { Block[] data = { new Block(), new Block(), new Block() }; ref Block dataToComputeRef = ref GetDataWithRef(ref data, 0); Block dataToCompute = GetData(ref data, 1); dataToComputeRef.DataBlock = 123; //ref, change in data dataToCompute.DataBlock = 124;//copy, no change in data }

Dzięki zastosowaniu zwracanej referencji w metodzie GetDataWithRef unika się zbędnego kopiowania danych i operuje się na oryginalnych danych.

Opinia

Mała drobnostka, która zapewne będzie powszechne wykorzystywana w projektach operujących na dużych strukturach danych.

ValueTask<T>

C# 7 pozwoli także na optymalizację kodu asynchronicznego. Do tej pory każda metoda asynchroniczna musiała zwracać void, Task lub Task<T> (gdzie Task był typem refrencyjnym). Teraz ma się to zmienić i będzie można zwracać także ValueTask<T>, typ strukturalny.

ValueTask ma być używany w przypadku, gdy już podczas wywołania metody asynchronicznej, znana jest zwracana wartość. Użycie tej struktury ma znacząco wpłynąć na wydajność, poprzez zmniejszenie ilości alokacji na stercie.

Opinia

Microsoft już ostrzega, iż poprawne wykorzystanie ValueTask<T> nie jest wcale trywialne. Użycie nowego bytu nie będzie powszechnie stosowane przez większość programistów, ale z pewnością wykorzystane zostanie w różnych zewnętrznych frameworkach i modułach. W obecnej, testowej wersji Visual Studio, nadal nie można było używać ValueTask.

Więcej expression bodied features

W C# 6 zaprezentowano metody expression bodied, które znacząco skracały pisanie jedno linijkowych metod. C# 7 dodaje możliwość skrócenia pisania konstruktorów, destruktorów oraz getterów i setterów.

public class Vehicle { public Vehicle(int fuel) => _fuel = fuel; ~Vehicle() => Debug.WriteLine("Finalizer called"); private int _fuel; public int Fuel { get => _fuel; set => _fuel = value; } } }

Opinia

Na ten moment rozszerzone użycie expression bodied nie zostało jeszcze wprowadzone. Microsoft szczyci się, że zmiany wyszły bezpośrednio od społeczności i to ona zasugerowała twórcom te nowości. Nie jestem jednak przekonany czy faktycznie powyższy kod zyskał na czytelności, a i skrócenie go o kilka nawiasów niewiele przyspiesza w ogólnym rozrachunku. Ot taka drobnostka.

Wyjątki w wyrażeniach

Drobnym dodatkiem jest także możliwość wyrzucania wyjątków bezpośrednio w wyrażeniach:

public string GetUserName(string userString) { return !(userString is null) ? userString.ToUpper() : throw new InvalidOperationException("No user string!"); } public string GetLoginFromDb(int id) => throw new NotImplementedException("GetLoginFromDb");

Opinia

Obecna wersja Visual Studio nie pozwalała na przetestowanie tej funkcjonalności.

Literały - usprawnienia

C# 7 dodaje także możliwość stworzenia literałów binarnych, a także rozdzielenia wpisanych wartości znakiem "_", w celu ułatwienia czytelności zapisu:

int value1 = 0b0010_1010; int phone = 000_000_000_111;

Opinia

Taka mała drobnostka, że może nawet nie być zauważona przez większość osób. Plusem jest głównie to, że nie trzeba pamiętać wartości heksadecymalnych przy ustawianiu bitów.

Wildcards

Na koniec wspomnieć trzeba jeszcze o jednym ficzerze, który nie jest jeszcze w 100% potwierdzony w C#7. Mowa o wildcards.

Mając metodę, która przyjmuje parametry out:

public void ComputeData(out int par1, out inr par2, out string par3) { //... }

Możemy wywołać ją z pominięciem parametrów wejściowych przy użyciu "dzikiej karty", w postaci znaku "*":

ComputeData(out int par1, *)

Identyczne można będzie postąpić w przypadku dekonstruktorów, poniższe wywołanie:

var (userName, userLogin, userPhone) = u;

zastąpić można:

var (userName, *) = u;

co oznacza, iż tylko pierwszy zwracany parametr out nas interesuje.

Opinia

Ta funkcjonalność również nie została jeszcze udostępniona... i mam nadzieję, że jej nie będzie w finalnym C#7. Jeśli połączymy wildcardy i przeciążenia w dekompozycji to otrzymamy niestrawny kotlet, który będzie nam się odbijał przez długi czas.

Podsumowanie

C# 7 to dość kontrowersyjne zmiany. Większość nowości i usprawnień nie do końca wydaje się być bardzo przydatna. Widać tutaj, że Microsoft chce koniecznie przenieść kolejne rzeczy dostępne już w języku F# do C#. Nie wiem tylko czy jest sens wrzucanie do języka obiektowego C# elementów z funkcyjnego języka F#. W wielu miejscach C# w wersji 7 zaczyna przypominać zmiany w JS z ECMAScript 6, co nie do końca jest będzie się podobać.

Przy kilu drobnych, ale przydatnych ficzerach jak out variables czy pattern matching są bardzo dyskusyjne nowości. Wspomnę tylko o nowych tuplach, dekompozycji czy funkcjach lokalnych. O ile ostatnie iteracje C# oferowały zawsze jakieś ciekawe zmiany (C# 5 - async/await, C# 6 - Elvis) to C# 7 jest dość kontrowersyjny.

Oczywiście nie jest to nadal wersja finalna, ale można przyjąć, że niezbyt wiele się tutaj zmieni. Ogólnie jestem trochę zawiedziony C# 7, a nawet zdegustowany kilkoma zaproponowanymi elementami.

Postęp prac nad C# 7 można obserwować na GitHubie. Link do blogu na MSDN

porady programowanie

Komentarze

0 nowych
pr0100   5 #1 25.10.2016 03:27

Czym różnią się "Local functions" od zwykłych funkcji anonimowych?

Autor edytował komentarz w dniu: 25.10.2016 03:27
  #2 25.10.2016 05:42

Ale zrobili śmietnik z tego języka. Kiedyś trochę zazdrościłem programistom C# ale teraz już wolę swoją Javę

  #3 25.10.2016 06:25

Fajnie, że dodają nowe mechanizmy do języka ale tak naprawdę to nie jest nic nowego. Pattern Matching, krotki, funkcje lambda działają w od lat w językach funkcyjnych(Haskell, Ocaml, ML) i Prologu.

djfoxer   17 #4 25.10.2016 07:48

@pr0100: Mam wrażenie, że funkcje anonimowe są bardziej reużywalne.

duszek.mestre   3 #5 25.10.2016 07:51

Dekompozycja bardzo kojarzy mi się z tym co jest w Matlabie/Octawave. Generalnie polega na tym, ze wywołując funkcję może ona zwrócić wiele wartości (podobnie się definiuje jak tuple w C# 7) i potem podczas wywoływania można te wartości odczytać. Jedna rzecz tylko - w matlabie nie trzeba przeciążać. Po prostu bierze się tam zwracane wartości po kolei. Czyli np. jeśli funkcja zwraca trzy wartości to Ty możesz wziąć 1, 2 lub 3. Tyle, ze w kolejności. Ale widząc po konstrukcji w C#7 to możliwe, ze zostanie to dość podobnie rozwiązane.

Edit: przeczytałem wildcardy i to już generalnie to samo. Po prostu nie bedą tworzone zmiennie, gdy dasz * :)

Autor edytował komentarz w dniu: 25.10.2016 08:01
__Tux__   12 #6 25.10.2016 08:18

Od długiego czasu mam wrażenie, że M$ chce uczynić C# fajnym. Dodawanie cukru składniowego to zły kierunek. Lepiej uprościć język zamiast jeszcze bardziej go komplikować.

mikolaj_s   13 #7 25.10.2016 08:52

Jak już chcieli zrobić fajnie z CASE to mogli wziąć za wzór Scalę czy Rust tam składnia jest trochę ładniejsza bez tych całych break

@__Tux__ Języki już tak mają, jak chce się rozszerzać ich funkcjonalność to dodaje się nowe elementy składni. Upraszcza się nowe języki, bo stare muszą być jako tako kompatybilne z poprzednimi wersjami.

@pr0100 "Czym różnią się "Local functions" od zwykłych funkcji anonimowych?"

Tym, że nie są anonimowe, czyli mają nazwę, dostępną w zakresie metody. :)

Autor edytował komentarz w dniu: 25.10.2016 09:00
kowgli   6 #8 25.10.2016 09:31

Nie spodziewałbym się takiego tekstu na DP, trochę ciężko się czyta (mimo że wiem dokładnie o co chodzi), ale tak czy siak podziwiam i gratuluję.
Warto może zalinkować "oryginalne" artykuły na ten sam temat, które moim zdaniem są trochę bardziej strawne - https://blogs.msdn.microsoft.com/dotnet/2016/08/24/whats-new-in-csharp-7-0/
https://blogs.msdn.microsoft.com/visualstudio/2016/08/30/new-c-7-0-features-in-v.../
Może to kwestia formatowania i tego, że język angielski jakoś bardziej się nadaje do opisywania rzeczy technicznych.

Nie do końca rozumiem uprzedzenie do nazwanych krotek (tuple) jako argumentów wyjściowych metod. Nawet biorąc pod uwagę ich specyfikę, jest to moim zdaniem o wiele lepsze rozwiązanie niż tworzenie całych klas jedynie na potrzeby pogrupowania paru wartości, na potrzeby jednej metody.

..........

Swoją drogą, to pierwszy link powinien znaleźć się w tekście, z informacją, że powyższy wpis jest w dużym stopniu tłumaczeniem postu z MSDN Blogs. W przeciwnym przypadku podchodzi to pod plagiat...

Autor edytował komentarz w dniu: 25.10.2016 09:43
TestamenT   11 #9 25.10.2016 09:35

@__Tux__: Nie lubię tego, mam nadzieje że Go pozostanie proste tak jak teraz i jedynie co będzie rozbudowywane to standardowa biblioteka.
Ale zauważyłem że JavaScript to służy, bo ten język był tworzony na kolanie więc z każdą wersją jest ciekawie. I dzięki ECMAScript.6 nawet zacząłem lubić ten język.

Autor edytował komentarz w dniu: 25.10.2016 09:36
Kaworu   12 #10 25.10.2016 09:35

@mikolaj_s: IMO switch/case/break to akurat całkiem dobra rzecz, opcja wywołania niższego case'a jest o tyle dobra, że czasem nie musisz wstawiać kilka razy tego samego kodu, cleanup po prostu robi najniższy case.

__Tux__   12 #11 25.10.2016 09:47

@TestamenT: O ECMAScript już kiedy wspomniałem: to taka szyszka w dupie, ani wyciągnąć ani wsadzać dalej. Jest stworzony nie tyle na kolanie, to w bólach i męczarniach, bo producenci przeglądarek nie mogli się zgodzić. Do tego dochodzi kwestia bezpieczeństwa. I niestety nic lepszego na razie nie da się zrobić. Ja wolę jak język rozwija się powoli, ale z pomysłem, niż ktoś miałby eksperymentować na ludziach. Podobnie jest z C++: standard cpp11 ma trochę nowości, ale powstawał 10 lat. cpp14 i cpp17 już takich zmian nie mają. To jest ewolucja, a nie rewolucja.
@mikolaj_s: Jeśli język dalej trzyma się pewnych koncepcji, to spoko. Zwracanie literałów krotek to akurat trochę złamanie zasad obiektowości, tzn. wypadałoby , żeby to była kolekcja a nie krotka (kolekcja z kolejnością, krotka ma strukturę). W Perlu, Pythonie i Ruby to jest od dawna, mieli z czego brać przykład. Można było też pomyśleć o typie auto. To tylko przykład. Ale cóż, tak wybrał M$.

djfoxer   17 #12 25.10.2016 10:09

@kowgli: Problemem jest zapewne to, że pisząc po polsku ciężko jest uniknąć angielskich wyrażeń. Wówczas mamy tekst gdzie część rzeczy jest po polsku, część po angielsku i nie czyta się tego zapewne tak płynnie jak tekstu po angielsku. Tłumaczenie wszystkiego na polski zapewne spowodowałoby dziwne słowotwórstwo.

Co do Tupli to w większych projektach jednak powoduje to niepotrzebne zaciemnianie kodu, nawet jeśli są używane lokalnie. Robiąc Code Review czy analizując kod jak widzisz zmienne Item1, Item2, Item3... to ciężko jest mówić o jasności kodu czy o refaktoryzacji nie wspominając już.

  #13 25.10.2016 10:15

Dzięki wielkie za Twoje wpisy:)
Przyznam się, że jestem małym leniem i nie czytam o nadchodzacych zmianach na strona MS, ale dzięki Twoim wpisom już nie pierwszy raz dowiaduje się o nowościach:)

Twój wpis dotyczący C#6 sprawił, że zacząłem używać parę nowości;)

djfoxer   17 #14 25.10.2016 10:27

@kowgli: Nie bądź śmieszny ;) Pewnie, że przeczytałem tekst na MSDNie, obejrzałem też film z Build 2016, byłem też na prezentacji Jon Skeeta, plus przeczytałem też kilka innych wpisów w sieci i porobiłem własne testy na VS15.

kowgli   6 #15 25.10.2016 10:39

@djfoxer: Zgadzam się, że używanie Item1, Item2, ... jest fatalne, jednak tutaj przecież mamy je nazwane, więc to jednak coś innego. Co z tego, że jedynie na poziomie kodu, a w CLR będzie i tak Item1, Item2, ...

Nie rozumiem dlaczego śmieszny? Choćby fragment o "Pattern Matching", w oryginale:
C# 7.0 introduces the notion of patterns, which, abstractly speaking, are syntactic elements that can test that a value has a certain “shape”, and extract information from the value when it does.

Examples of patterns in C# 7.0 are:

* Constant patterns of the form c (where c is a constant expression in C#), which test that the input is equal to c
* Type patterns of the form T x (where T is a type and x is an identifier), which test that the input has type T, and if so, extracts the value of the input into a fresh variable x of type T
* Var patterns of the form var x (where x is an identifier), which always match, and simply put the value of the input into a fresh variable x with the same type as the input.

U ciebie:
Jednym z ciekawszych ficzerów w nowej odsłonie C# jest Pattern matching. Funkcjonalność ta daje name możliwość sprawdzenia warunku wartości, a następnie przetworzenie tej wartości, jeśli warunek jest prawdziwy. Patterns są nowymi elementami języka C#. W obecnej fazie do dyspozycji mamy następujące wzorce:
* constant patterns: c - gdzie c jest wyrażeniem constant w C#, wzorzec testuje czy wejście jest równe wyrażeniu c
* type patterns: T x - gdzie T jest typem, a x identyfikatorem, wzorzec sprawdza czy wejście jest typu T i jeśli tak jest wartość z wejścia podstawia pod nową zmienną x typu T
* var patterns:var x - gdzie x jest nazwą nowej zmiennej, wzorzec (sprawdzenie jest zawsze prawdziwe) jedynie ustawia wartość z wejścia pod nową zmienną x o typie takim jak wejście

To nie jest "przeczytałem", tylko po prostu tłumaczenie. Bez zgody autora i z jasnym zaznaczeniem źródła, jest to plagiat.

Autor edytował komentarz w dniu: 25.10.2016 10:41
  #16 25.10.2016 10:45

@__Tux__: Przecież w c# zamiast "auto" masz "var".
A krotki są takie same jak w Pythonie. W nowych Py masz nawet namedtuple w bibliotece standardowej.

s77s   7 #17 25.10.2016 10:53

Pattern matching i Tuple jest lepiej zrobione w języku Elixir.

W skrócie działa to następująco:
def something() do
{:ok, "result"}
end
{:ok, result} = something()
IO.inspect result # "result"

Oraz w przypadku case:
case {1, 2, 3} do
{x, 5, y} ->
IO.puts "ten komunikat się nie wyświetli"
{x, 2, y} ->
IO.puts x # 1
IO.puts y # 3
true ->
IO.puts "kiedy wszystko inne zawodzi ..."
end

Przy czym pattern matching działa ze wszystkimi typami danych np. w podanym przykładzie case może być zwykły napis, mapa, lista i inne.
Oczywiście typy też można sprawdzać i deklarować typ argumentów funkcji.

Jak patrzę na co poniektóre przykłady "nowości" w C# to cieszę się, że tego nie używam :-) Tak jak zauważyłeś jest tam sporo możliwości tworzenia nieczytelnego kodu.

  #18 25.10.2016 10:57

@s77s: Napisałeś coś w tym Elixirze?

djfoxer   17 #19 25.10.2016 11:21

@kowgli: Ehh. Zgłoś do MS że po przeczytaniu m.in. ich tekstu napisałem własny tekst i przy opisie patterm matching w punktach bazował na ich opisie. Zamiast samemu wymyślić i opisać własny patter matching ;)

  #20 25.10.2016 11:52

@__Tux__: "Można było też pomyśleć o typie auto."

Masz na myśli coś a la var? Na przykład:
var theAnswer = 42; czy var answers = new List(); ?

  #21 25.10.2016 11:56

@djfoxer: Przesadzasz trochę z tym niestrawnym kotletem.
Nie znając F# niektóre z rozwiązań przypominają mi niezmiernie elementy, które strasznie spodobały mi się w Scali, więc jeśli ktoś ma zacięcie funkcyjne są miłym dodatkiem. Niemniej słowem kluczowym jest tutaj "dodatek"...

pocolog   11 #22 25.10.2016 12:26

@kowgli: Chyba trochę gwiazdorzysz...

mikolaj_s   13 #23 25.10.2016 12:51

@__Tux__: Mnie akurat nie podobały się zmiany w C++, właśnie z podobnych powodów jak Twoje względem C#. Teraz siedzę głownie w Scali i tam mi to nie przeszkadza. Samemu trzeba się pilnować aby pisać czytelnie.

@Kaworu Co kto lubi :) Ja się już tak oduczyłem, że jak gdzieś muszę pisać switch to wkurza mnie że zapominam break. Wywoływanie kilku kolejnych casów jest rzadkością, a jak jest potrzebne załatwia się funkcją.

s77s   7 #24 25.10.2016 13:25

@Roman syn Ryżu (niezalogowany): Jestem w trakcie :-). Ogólnie obadałem wiele języków i póki co ten najbardziej spełnia moje wymagania i bardzo go sobie chwalę. Jedynym minusem (nie dla mnie) może być to, że język ten jest funkcyjny, tzn. nie ma klas. Jest bardzo funkcjonalny i o wiele łatwiejszy w nauce od Erlanga i C# (tu bazuję na ów nowinkach w tym Tuple i pattern matching). Ma wiele zalet i naprawdę warto zagłębić się trochę. Phoenix jest świetnym frameworkiem, a Ecto też daje radę, ale w niektórych warunkach przydałoby się, aby zapewniał też to co pojedyncze bazy danych (jest on nastawiony właśnie na uniwersalność i czasami trzeba szukać dodatkowych pakietów np. dla pola typu enum).

__Tux__   12 #25 25.10.2016 13:30

@__null (niezalogowany): Nie do końca, bo zachowanie będzie trochę inne. W językach stosujących słowo var oznacza RÓWNIEŻ zakres w jakim zmienne mają się znajdować. W przypadku auto w C++, kompilator dedukuje typ za pomocą mechanizmu podobnego do szablonów.
@mikolaj_s: Z tym, że C# i C++ mają trochę inny charakter. C++ poza składnią musi trzymać się pewnych zasad dotyczących generowania kodu maszynowego, typu manglowanie nazw. Dlatego nie zawsze każdą nowinkę da się implementować tak łatwo. M$ nie musi się zastanawiać nad architekturą procesora.

  #26 25.10.2016 13:35

@Anonim (niezalogowany): Ta a obiektówka w Javie jest dość udziwniona. To już lepiej Rust szybko wydajnie nowocześnie.

__Tux__   12 #27 25.10.2016 15:03

@s77s: Dlatego należy używać języków zgodnie z przeznaczeniem. Nie każdy umie to robić, naprawdę. I nie zawsze wydajność i czytelność są najważniejszymi kryteriami. C# jest dobry jak mam np. graficznie zrobić sobie grę w statki czy kalendarz, a do kodu zajrzeć raz. Jak mam w Visual Studio kliknąć na clickEvent do okienka, napisać parę linijek i tyle, to ok - wszystko robi za mnie środowisko RAD :-) .

s77s   7 #28 25.10.2016 17:05

@__Tux__: Można prościej w prostym Pythonie połączyć z już istniejącym językiem w czystym C (jeśli dobrze pamiętam, gdzieś był do tego kurs, ale nie zagłębiałem się) :-)

__Tux__   12 #29 25.10.2016 20:10

@s77s: Można, bawiłem się tym. Chociaż obiekty Pythona w C wyglądają dziwnie, ale da się żyć.

  #30 25.10.2016 22:20

Dekonstrukcja super, poza tym nic ciekawego. A kawałek o zwracaniu referencji mnie rozbawił, mam rozumieć że normalnie c# zwracając obiekt go kopiował? Ekhm, po co skoro można bez pytania dać oryginał? Halo, słówko return kończy wykonanie funkcji i już tam nie potrzeba tego obiektu, więc można niejawnie zwrócić adres na niego. Inna sprawa, kiedy wcześniej odpali się tam wątek z lamdą przechwytującą ten obiekt, ale ogarnięcie tego to zadanie kompilatora. Kazanie programiście sprecyzować kiedy chce zwrócić referencje to chory żart.

  #31 25.10.2016 22:37

@Anonim (niezalogowany): Przecież nie musisz wszystkiego stosować. Mi też się nie podobają zmiany w C#, ten język osiągnął kres rozwoju - teraz mogą zatracać pierwotny charakter i modyfikować tak, że pozostanie tylko nazwa.
Może zamiast pieprzyć kolejne wersje c# niech się skupią na rozbudowie Net.CORE bo na razie to obraz nędzy już nie mówiąc o tasowaniach typu opis projekt z xml do json i z powrotem.

  #32 26.10.2016 00:25

@anonim (niezalogowany): Gdyby Brackets miał taki wbudowany kompilator console jak WebStorm byłby idealnym IDE do JavaScript. A tak to jest jeszcze Atom, Sublime, KDEvelop, a to VS pod Linux to jakaś porażka.

  #33 26.10.2016 02:23

To warto się uczyć C# Xamarin?

djfoxer   17 #34 26.10.2016 23:23

@Anonim (niezalogowany): Warto :)

  #35 27.10.2016 15:51

@djfoxer: Lepiej JavaScript, Microsoft łapówkami zawyża ranking Tiobe i ten C# wcale nie jest na 4 miejscu.

djfoxer   17 #36 27.10.2016 20:21

@Anonim (niezalogowany): I wszystko jasne ;)

kop524   4 #37 28.10.2016 09:23

Mi po instalacji 15 Prev 5 pisze, że "Wygasła Licencja" i mogę tylko zamknąć progsa i nic więcej :( ktoś wie co z tym zrobić lub jak ominąć??? Może klucz do 2015 Ent coś da ???

  #38 31.10.2016 17:15

@kop524: najlepiej nie promować korporacyjnych języków programowania, co wyprawia Oracle z Java? Jest tyle innych możliwości Open Source na których programiści zarabiają więcej niż praca korporacyjnego szczura. W USA programista Ruby on Rails zarabia więcej niż Javowiec, C#.