• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    TENCOKACISTROMYProgramovani v C#, F# a dalsich jazycich pro .NET, Mono a ostatni CLI implementace
    TOOMIX
    TOOMIX --- ---
    LARS_GUNNER: Blazor
    BRAP242
    BRAP242 --- ---
    LARS_GUNNER: blazor.
    LARS_GUNNER
    LARS_GUNNER --- ---
    Budu delat webovou apku. Blog. Jeden admin ucet a data ven dostupna pres REST API. ASP.NET nebo Blazor nebo Xamarin?
    TOOMIX
    TOOMIX --- ---
    Adding color to bracket pairs - Visual Studio Blog
    https://devblogs.microsoft.com/visualstudio/adding-color-to-bracket-pairs/

    NECROMAN
    NECROMAN --- ---
    MORMEGIL: List implementuje IEnumerable interface, takže je možné ho vrátit jako IEnumerable bez konverze.
    PJOTRIK
    PJOTRIK --- ---
    Tak jasne, neni to silver bullet, ani objev ktery by prekvapil zkusenyho programatora... ale pri code review se s podobne neefektivnim kodem potkam kazdou chvili. A tenhle kanal je hlavne cileny na relativni zacatecniky nebo max prumerny developery imo
    MORMEGIL
    MORMEGIL --- ---
    NECROMAN: Tak hlavně někdy je to právě naopak: pokud tu příslušnou sekvenci umím generovat postupně (inkrementálně), tak IEnumerable mi umožní to přenést i ke konzumentovi a není pak problém zpracovat bambilion záznamů, aniž bych musel mít terabajty RAM. (Ale ano, pokud nějaká metoda vypočítá List, tak je nesmysl vracet ho jako IEnumerable.)
    NECROMAN
    NECROMAN --- ---
    NECROMAN: a ještě k té složitosti
    Immutable collection algorithmic complexity - Developer Support
    https://devblogs.microsoft.com/premier-developer/immutable-collection-algorithmic-complexity/
    NECROMAN
    NECROMAN --- ---
    NECROMAN: samozřejmě všechno je to o tom, kde to chceme použít a jak, zda primárně pro reprezentaci dat, nebo add/remove operace, nebo seek operace...

    NECROMAN
    NECROMAN --- ---
    TOOMIX: tak to hodně záleží na kontextu. Jsou situace, kdy nechceš alokovat nový List pro nějaký výsledek Linqu nebo IQueryable. Použití IEnumerable má v určitých situacích svůj význam.
    Samozřejmě moudří vědí, že při definování kontraktů a návratových hodnot je lepší používat IReadOnlyList, který konzumenta upozorní, že v kolekci, co dostane, by neměl provádět změny.
    A ještě moudřejší vědí, že existují Immutable Collections, které dají konzumentovi jistotu, že ani nikdo jiný mu pod rukama nezmění data, která dostal.
    .NET Framework - Immutable Collections | Microsoft Docs
    https://docs.microsoft.com/en-us/archive/msdn-magazine/2017/march/net-framework-immutable-collections
    SADSOUL
    SADSOUL --- ---
    Nebyl by vhodnější IReadOnlyCollection?
    TROGLODYT
    TROGLODYT --- ---
    MORMEGIL: "místo IEnumerable používat List, protože se pak při práci s tou kolekcí zbytečně neplácají zdroje na znovunačítání té kolekce"
    MORMEGIL
    MORMEGIL --- ---
    ZBYNEK: Ono by se bez jedenáctiminutového videa ukázalo, že veškerý informační obsah se dá shrnout do jedné věty. ;-)
    TOOMIX
    TOOMIX --- ---
    ZBYNEK: on má všechna videa kolem těch 10 minut.

    Ve výsledku ale říká, že se má místo IEnumerable používat List, protože se pak při práci s tou kolekcí zbytečně neplácají zdroje na znovunačítání té kolekce. A to demonstruje na tom videu
    ZBYNEK
    ZBYNEK --- ---
    TOOMIX: Ať jdou s těma videama do prdele... 11 minut nebudu sledovat.

    To už lidi nejsou schopní napsat článek?
    TOOMIX
    TOOMIX --- ---
    How IEnumerable can kill your performance in C#
    https://www.youtube.com/watch?v=cLsmW7a8MkU
    SHIGORBIRDMAN
    SHIGORBIRDMAN --- ---
    MORMEGIL: "vyžadování povinných položek pro inicializaci třídy máme odjakživa, říká se tomu konstruktor" - presne tak...
    MORMEGIL
    MORMEGIL --- ---
    SHIGORBIRDMAN: No… prý v plné obecnosti je. Jasně, v základním případě to není potřeba, ale při volání konstruktoru předka, případně jiných konstruktorů se to začne komplikovat… V komentářích tam píšou, že nejdříve začali vymýšlet jakýsi „anotační jazyk“, který by popisoval, které konkrétní členy ten konkrétní konstruktor nastavuje, aby se to dalo postupně skládat a vyhodnocovat, načež došli k tomu, že to jsou strašné komplikace, které za to nestojí, a vyřešili to takhle. Což za mě vůbec nedává smysl; pokud vidím, že se z té zdánlivě jednoduché funkčnosti stává moloch, tak buď rovnou zahodím celou tu potenciální funkčnost (jako co to vlastně přináší? vyžadování povinných položek pro inicializaci třídy máme odjakživa, říká se tomu konstruktor!), anebo to nějak oříznu na opravdu nejjednodušší případy (chcete používat required členy? tak asi píšete jednoduchou třídu bez konstruktoru a budete ji naplňovat inicializátory; píšete třídu s mnoha složitými konstruktory volajícími konstruktory předků atd.? tak serte na syntaktický cukr required a vyřešte to v těch konstruktorech!).
    SHIGORBIRDMAN
    SHIGORBIRDMAN --- ---
    MORMEGIL: hmmm... pritom nejak nechapu, PROC to musi byt... to je takovy problem pro compiler podivat se, jestli constructor nastavuje ty required members? :/
    TOOMIX
    TOOMIX --- ---
    MORMEGIL: to je jen kvůli zpětné kompatibilitě, ale taky bych se na to vykašlal. .NET 5 není LTS verze, takže by na produkci být neměla
    MORMEGIL
    MORMEGIL --- ---
    TOOMIX: Zato ten [SetsRequiredMembers] je dobrá záplata… :-/ Fakt nevím, jestli je nutný takovýhle věci do jazyka cpát…
    SHIGORBIRDMAN
    SHIGORBIRDMAN --- ---
    TOOMIX: ooooh.... konecne, konecne genericka matika, to byla jedna z mala veci, co me na c# od zacatku neskutecne tocila, ze nemuzu snadno psat genericke funkce pro float / double a musim to kopirovat...
    Kliknutím sem můžete změnit nastavení reklam