Tworzenie tablic obiektów/klass

Co kto lubi, ale klamry trudno traktować jako linie kodu.

To czemu moj kod zmodyfikowales, zeby klamra zajmowala cala linie?

Hahaha, lubię z Tobą dyskutować. :D Nie muszę wiedzieć co to jest Action<t>, ale muszę wiedzieć co to jest Action<t>

Hahaha, lubie z Toba dyskutowac. :D A szczegolnie gdy nazywasz moje skoki warunkowe zlymi, a swoje dobrymi.
Mozemy zjechac jeszcze nizej, tylko po co?
Chyba nie jest ci dane zrozumiec, ze slowo metoda jest proste, a Action<T> to detal techniczny. Przykro mi.

Tak, ale nie zawsze potrzeba abstrakcji. :)

Moze i nie potrzeba, ale nie znaczy to, ze nie jest ona latwiejsza.

To czemu moj kod zmodyfikowales, zeby klamra zajmowala cala linie?

VS zmodyfikował, a w swoim kodzie użyłbym takiego samego formatowania. :) To nie jest konkurs czy zapiszę rozwiązanie w 20 linii, czy w 21 tylko chodziło mi o udowodnienie, że to nie jest gigantyczna różnica. Nie zejdziesz z 10->4 czy jakoś tak. Prawie nic nie zaoszczędzasz. :)

Chyba nie jest ci dane zrozumiec, ze slowo metoda jest proste, a Action<T> to detal techniczny. Przykro mi.

Dalej chyba nie rozumiesz. Wytłumaczę łopatologicznie: Nie trzeba wiedziec co to Action<t>, jak to dziala i po co to jest., jeżeli nie wiem co to Action<T>, to nie wiem co to jest Action<T>... Rozumiesz? Nie wiem, że Action<T> to delegat. Widząc w kodzie sygnaturę Xyz(Abc<T>) i nie wiedząc czym jest Abc<T> nie mogę napisać metoda przyjmuje metode o jakiejstam sygnaturze. Dopiero w dokumentacji widzę komentarz Abc<T> to delegat i mogę powiedzieć Xyz przyjmuje metode o jakiejstam sygnaturze.

Moze i nie potrzeba, ale nie znaczy to, ze nie jest ona latwiejsza.

Jeżeli abstrakcja jest zbędna, to jest zbędna i wtedy nie ułatwia życia...

Kod, ktory modyfikowalem zajmuje 32 wiersze. Moj kod zajmuje wierszy 20. Natomiast twoja manipulacja wskazuje, ze moj kod jest dluzszy od tego, ktory modyfikowalem.

Anyway... 'Trace' 4 wiersze na metode ToString(), z ktora myslalem, ze nikt sie nie bedzie klocic, ze jest to lepsze rozwiazanie. Wiec tak, jest duza roznica.

Dalej chyba nie rozumiesz. Wytłumaczę łopatologicznie:

Dobrze, pokaz mi gdzie w kodzie wystepuje to Action<T>.

Jeżeli abstrakcja jest zbędna, to jest zbędna i wtedy nie ułatwia życia...

Hmm.. okej. Mozesz tak uwazac.

W takim razie przypomnij czemu w ogole w C#? Ano... w sumie mozna i w asmie, zajmie troche wiecej miejsca, ale bez watpienia nadaje sie do tego zadania. Ale, hmm... asm to w gruncie rzeczy tylko abstrakcja, Czemu by nie napisac w kodzie maszynowym?

Dobrze, pokaz mi gdzie w kodzie wystepuje to Action<T>.

Jeszcze raz, żeby zrozumieć kod potrzebuję:

        Person[] persons = new Person[10];
        for (int i = 0; i < 10; i++)
            persons[i] = new...

1. Wiedzieć jak się deklaruję tablicę.
2. Wiedzieć jak zrobić for, czyli to sprowadza się do zrozumienia for + tego co zawiera czyli

for ( 1; 2; 4; ) 
   3

1. Inicjalizacja int = 0
2. Jeżeli warunek i < 10 nie jest spełniony
3. Ciało persons[i] = new
4. Iteracja i++

Czyli w sumie potrzebuję wiedzieć jak zadeklarować tablicę i jak działa for i kilka trywialnych rzecz (deklaracja zmiennej, porównanie, inkrementacja).

        var persons = Enumerable.Range(0, 10)
                                .Select(i => new Person })
                                .ToList();

1. Wiedzieć co robi Range. Już teraz zahaczam o szablony. :) Sprawdzam w dokumentacji dowiaduję się że zwraca {0,1,2,3,4,5,6,7,8,9}.
2. Wiedzieć co robi Select() czyli patrzę do dokumentacji i widzę public static IEnumerable<TResult> Select<TSource, TResult>(this IEnumerable<TSource> source, Func<TSource, TResult> selector ) (dość odpychające :)) spotykam metodę rozszerzającą. Jakby tego było mało potrzebuję wiedzieć co to Funcpatrzę w dokumentacji public delegate TResult Func..., ale co to jest delegat? :) Na deser dochodzi lambda expression.
3. ToList - ok teraz z górki.

Czyli żeby użyć ze zrozumieniem potrzebowałem się dowiedzieć o szablonach, delegatach, Func<T>, lambda expression, metoda rozszerzająca, Range, Select, ToList, List<T>.

Kod, ktory modyfikowalem zajmuje 32 wiersze. Moj kod zajmuje wierszy 20. Natomiast twoja manipulacja wskazuje, ze moj kod jest dluzszy od tego, ktory modyfikowalem.

Nie, Twój kod zajmuje 4 linie, bo nie napisałeś reszty. :) Odnośnie długości...

        var array = ...;
        for (int i = 0; i < array.Length; i++)
            array[i] = ...

        var persons = Enumerable.Range(0, 10)
                                .Select(...)
                                .ToList();

Co do abstrakcji, to piszę o zbędnej abstrakcji. Napisałeś kod persons.ForEach(Console.WriteLine);, a może zrobić:

    static void Wyswietl<T>(T s)
    {
        Console.WriteLine(s);
    }

Zwiększe abstrakcję, ale nic z tego nie mam.

Jeszcze raz,

Jeszcze raz... jak napisales hello-worlda?

Zwiększe abstrakcję, ale nic z tego nie mam.

Masz. Choc akurat nie w tym przypadku. W tym przypadku wprowadzasz komplikacje do metody Console.WriteLine.

using System;

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Hello world!");
    }
}

Masz. Choc akurat nie w tym przypadku.

Tak ale nie. :) I tak od kilku stron. :)

Przed napisaniem tego kawalka kodu oczywiscie wiedziales:
#Co robi using?
#Czym jest System?
#Co to przestrzen nazw?
#Co to klasa?
#Po co ta klasa? (wtf man, chce tylko napis na ekran wyswietlic)
#Czym jest static?
#Co powoduje to static?
#Dlaczego void?
#Co znaczy void?
#Dlaczego akurat Main?
#Czemu ta tablica stringow?
#Czym jest string?
#Czym jest tablica?
#Czym jest Console?
#Jak wyglada WriteLine?
#Jakiego typu jest ten literal?

Dosc duzo co nie? A pewnie cos jeszcze pominalem po drodze. Juz teraz rozumiesz czym jest ukrywanie szczegolow technicznych, czy wciaz nie bardzo?

n0name_l napisał(a):

Nie, napisales, ze nie pasuje do funkcjonalnego podejscia, ktore towarzyszylo przy tworzeniu LINQ poniewaz metoda ta polega na efektach ubocznych. Calkowita racja.
W jezyku imperatywnym nie spodziewam sie natomiast ograniczen ze wzgledu, ze cos polega na efektach ubocznych, czyz nie?

C# to język, który został zaprojektowany, tu nie tworzy się spaghetti, bo ktoś uważa, że spaghetti jest fajne. Skoro zaimplementowano zestaw metod, których założeniem jest ZAWSZE zwracać wartość, to nie dokleja się do nich nagle metody, która niczego nie zwraca.
Kolekcje mutowalne mają metodę pozwalającą zmieniać stan obiektów, kolekcje niemutowane jej nie posiadają. Jest to spójne i sensowne.

Skoro moge uzywac skladni:
foreach(var elem in dict) {}, czemu nie moge uzyc metody ForEach?

Możesz użyć, jeśli lubisz, sam też używam. Ale nie twierdzę, że powinna być tam, gdzie jej być nie powinno.

Przeciez C# to nie jezyk funkcyjny, wiec moze ideologozimy na bok odstawimy?

Jakie ideologizmy? Spójność i konsekwencja to podstawy solidnego działania w każdej dziedzinie, nie żadna ideologia.

Gdybym nie musial uzywac tych liczb, to bym wcale sekwencji liczb nie generowal, bo i po co?

No, a w tym przypadku to generowanie nie ma sensu, bo jest tylko przykładem na siłę. Po co je w ogóle pisać? Po co powtórzyłeś po @ne0 ten bezsens?

Nie, postanowilem skrocic za pomoca ForEach jednoczesnie wskazujac, ze budowanie reprezentacji tekstowej powinno byc odpowiedzialnoscia klasy, a nie funkcji Main.

Ale, żeby użyć ForEach musiałeś najpierw użyć ToList. Czyli robisz coś niepotrzebnie, żeby potem zrobić coś "fajnie", zamiast wszystko zrobić najprościej jak się da.

Co do przeciążenia ToString, to jest oczywiste, że tego się powinno użyć, i nie do tego się przyczepiłem. Tylko też nie napisałeś tego jasno w tamtym poście, więc nie każdy musiał zrozumieć. Zwłaszcza nie każdy początkujący.

Moj kod nie jest w C# wedlug czego? Kompilator ma sie z nim dobrze.

Można napisać kod w C# kod C (wszystko public static, globalne zmienne, żadnych klas, itp.), Ty próbujesz chyba przegiąć w drugą stronę.

Anyway... Jak chcecie pisac 10 linijek kodu zamiast 4, ktore robia dokladnie to samo to jest to wasza sprawa.
Natomiast jak mowicie:
#Petla for jest podstawowa konstrukcja programistyczna
#Petla for jest prostsza od wywolania metody
#Zeby skorzystac z mojego kodu trzeba wiedziec co to generyki
#Kod stworzony przy pomocy petli for jest bardziej czytelny czy intuicyjny od tego z wywolaniami metod

Nie mów do mnie w liczbie mnogiej, ja jestem jeden. I nie tworzę durnych przykładów, żeby pokazać jedną metodę z LINQ.

Ad 1. Tak, pętla for to podstawowo konstrukcja C#. Jeśli jej nie znasz, to nie możesz mówić, że znasz choćby podstawy tego języka.
Ad 2. Te rzeczy są w ogóle nieporównywalne, to tak jakby spytać czy lepsza jest pralka czy lodówka.
Ad 3. Żeby korzystać może nie, ale żeby skorzystać świadomie już tak. A korzystanie nieświadome powoduje zazwyczaj stworzenie badziewia.
Ad 4. Zależy jaki kod.

n0name_l napisał(a):

spójrz na to czego uczą na "wstępie do programowania"

Lispa?

A gdzie konkretnie?

Nie rozumiem twojego podejscia.
Moge napisac cos takiego:

IEnumerable<int> coll = ....
foreach(var elem in coll) {
  ....
}

Uzywam tutaj oczywiscie z zalozenia niemutowalnej kolekcji i instrukcji, ktora polega na skutkach ubocznych.

Ale dodanie czegos takiego:

coll.ForEach()

Juz jest niekonsekwencja?
Zarowno ta konstrukcja jak i ta metoda sa uzywane w identycznym celu. Zadne z nich nie zwraca wartosci i obie polegaja na skutkach ubocznych.

Po co powtórzyłeś po @ne0 ten bezsens?

Napisalem tylko jego kod w alternatywny sposob, nic wiecej nie robilem. Czemu mialbym cos zmieniac?

musiałeś najpierw użyć ToList

Tak, wspomnialem, ze musze zrobic kilka dodatkowych operacji, zeby calosc dzialala. Niestety, uzywanie ToList(), tylko w tym celu co przedstawiony jest bolesne. Ale inaczej przyklad by nie mial zbytnio sensu.

Ad 1.

Podstawowa konstrukcja jezykowa != Podstawowa konstrukcja programistyczna.

Ad 2.

A mi z latwoscia przyjdzie stwierdzenie, ze komputer jest bardziej skomplikowanym mechanizmem niz cep.

Ad 3.

Korzystanie pol-swiadome jest za to zdrowe dla nowicjuszy. Nie musza byc ani przytlaczani masa rzeczy, a moga napisac cos co pokaze im jakis efekt, w krotkim czasie. Chyba, ze sie myle i przed napisaniem slowka class trzeba poznac co to dziedziczenie?

A gdzie konkretnie?

Na MIT swego czasu, sam nie wiem czy wciaz.

n0name_l napisał(a):

Zarowno ta konstrukcja jak i ta metoda sa uzywane w identycznym celu. Zadne z nich nie zwraca wartosci i obie polegaja na skutkach ubocznych.

I z uwagi na te skutki uboczne dodanie tego do System.Linq.Enumerable byłoby niekonsekwencją, skoro wszystkie pozostałe metody tej klasy zwracają wartość, a nie skutkują ubocznie.
Wygrzebałem specjalnie dla Ciebie: http://blogs.msdn.com/b/ericlippert/archive/2009/05/18/foreach-vs-foreach.aspx

Napisalem tylko jego kod w alternatywny sposob, nic wiecej nie robilem. Czemu mialbym cos zmieniac?

W pewnym wieku po prostu nie wypada powtarzać głupot po innych.

Tak, wspomnialem, ze musze zrobic kilka dodatkowych operacji, zeby calosc dzialala. Niestety, uzywanie ToList(), tylko w tym celu co przedstawiony jest bolesne. Ale inaczej przyklad by nie mial zbytnio sensu.

A w praktyce w takim przypadku powinniśmy po prostu utworzyć List<Person>, odpytać użytkownika o wpisanie danych do utworzenia obiektów (zapewne korzystając jakiegoś okrutnego while), dodać do listy tyle obiektów, ile sobie użytkownik zażyczy, i na koniec możemy wywołać ForeEach bez nadmiarowego ToList().

Podstawowa konstrukcja jezykowa != Podstawowa konstrukcja programistyczna.

Pętle są podstawowymi konstrukcjami programistycznymi, które musi znać każdy, kto się programowaniem zajmuje. Bez znajomości iteracji nie sposób zrozumieć większości algorytmów.

A mi z latwoscia przyjdzie stwierdzenie, ze komputer jest bardziej skomplikowanym mechanizmem niz cep.

Niewątpliwie, ale to nie ma żadnego związku.

Korzystanie pol-swiadome jest za to zdrowe dla nowicjuszy. Nie musza byc ani przytlaczani masa rzeczy, a moga napisac cos co pokaze im jakis efekt, w krotkim czasie. Chyba, ze sie myle i przed napisaniem slowka class trzeba poznac co to dziedziczenie?

A potem taki pół świadomy użytkownik przychodzi na forum z kodem, którego kompletnie nie rozumie, sklejonym z różnych znalezionych w internecie zlepków, który jest 10 razy dłuższy niż powinien być, i prosi o pomoc w znalezieniu błędu.
Ok, nie trzeba wszystkiego tłumaczyć od razu, ale pokazywanie generyków, delegatów i lambd komuś, kto nie zna pętli i metod, nie ma sensu dydaktycznego.

Na MIT swego czasu, sam nie wiem czy wciaz.

Czyli mało gdzie.

nie skutkują ubocznie

Jestes pewien? Bo formalnie to moga.

enumerable.Select(x => {
  Console.WriteLine(x);
  return x;
}).ToList();

ForEach tez moze zwracac wartosc oczywiscie.

public static IEnumerable<T> ForEach<T>(this IEnumerable<T> enumerable, Action<T> action)
{
  foreach(var elem in enumerable)
  {
    action(elem);
  }

  return enumerable;
}

O dziwo, ma to swoje plusy.

W kazdym razie argumentacja to kosztowne ma sens, argumentacja to glupota go nie ma.

Czyli mało gdzie.

Kiedykolwiek miala ilosc znaczenie?

n0name_l napisał(a):

Przed napisaniem tego kawalka kodu oczywiscie wiedziales:

Tak. :) Jednak nie potrzebuje wiedzieć tych rzeczy żeby napisać kod. Kiedy chcę powiedzieć "rozumiem co ten kod robi", to wypadałoby znać większość punktów które wymieniłeś.

Dosc duzo co nie? A pewnie cos jeszcze pominalem po drodze. Juz teraz rozumiesz czym jest ukrywanie szczegolow technicznych, czy wciaz nie bardzo?

Ja nie piszę o "szczegółach technicznych", a o elementach niezbędny do użycia kodu. Przykładowo żeby skorzystać z Select trzeba wiedzieć czym jest Func<T>, ale już o tym pisałem wcześniej.

n0name_l napisał(a):

Kiedykolwiek miala ilosc znaczenie?

Zawsze i wszędzie.