Poslední příspěvky

Stran: [1] 2 3 ... 10
1
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Jiří Havel kdy Dnes v 12:48:56 »
Ale pro potřeby návrhu softwaru je účelnější se na to dívat z nějaké přirozenější a člověku bližší perspektivy. Když někdo orazítkuje papír, tak se jeho stav změnil (nebudu si hrát na to, že dokument je pořád stejný, jen se v jeho blízkosti zrovna vyskytují molekuly barvy; nebo že v mojí představě je pořád dokument neorazítkovaný, protože jsem ho viděl naposledy včera a pamatuji si ho tak).
No právě. Opravdu se ten dokument mění? Je furt stejný, jen jsme k němu přidali nějaké ověření. Že je to jiný inkoust na stejném papíře je nepodstatný detail. V programu to může být druhý objekt, který se odkazuje na ten původní nezměněný dokument.
2
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Franta Kučera kdy Dnes v 12:47:43 »
Pokud objekt osoba svou váhu znát nepotřebuje, tak je lepší to zvazitSe. Protože Osobě odpadá starost s udržováním aktuální váhy.

Myslím, že jde hlavně o to, kdo ten algoritmus píše a kdy, jestli jsou algoritmy známé v době napsání té třídy nebo jestli mohou nějak nekontrolovateleně vznikat i později… a čí odpovědnost tyto algoritmy jsou (princip SRP).

Ta váha je příliš jednoduchá, proto je to zavádějící (člověk přece zná svoji váhu, je to jen jedno číslo, tak si ho může pamatovat a mít metodu, kterou nám váhu sdělí). Ale ten algoritmus může být mnohem složitější, může něco počítat rekurzivně nad celým stromem objektů a hlavně můžeme mít řadu alternativních algoritmů, můžou pracovat nad různými daty, můžeme chtít, aby je mohl definovat i někdo jiný později než byla definována daná třída. Tohle pak vede k tomu, že ten algoritmus (metoda) často patří jinam než do té třídy, nad kterou pracuje.

(taky můžeme dojít k tomu, že to je odpovědnost té třídy, nebo že chceme vědomě porušit princip SRP, ale to budou asi dost výjimky)
3
Hardware / Re:Rozdílné barvy na monitorech Dell a Mac
« Poslední příspěvek od Marek Staněk kdy Dnes v 12:46:52 »
Na těch Dellech to má ten prostý důvod, že to je režim pro oči nejmíň unavující. A jelikož nedělám nic, kde bych přesné barvy potřeboval, je pro mě klíčové právě to, aby mi to nevypalovalo díru do hlavy. Osobně bych za ideál považoval e-ink, ale 80 tisíc za 2x 24" fakt nedám.
Ve skutečnosti pro tebe je principiálně relevantní metrika hlavně to, že to na kalibrovaném displeji vypadá tak, jak to vypadat má a jak to zákazník chce, protože TO a nic jiného ti zaplatí. Právě proto to pro tebe smysl má. Pro mě ne, já to nepotřebuju, a naopak mi to spíš vadí. Říkej mi kvůli tomu klidně "hlupáku", mám to na salámu. Tvoje profesní deformace je tvůj problém.
4
Bazar / Re:Prodám Calibrite ColorChecker Studio
« Poslední příspěvek od jetsk kdy Dnes v 12:34:57 »
Mám k monitoru Color Navigator 7, snad bude kompatibilní. Mám zájem. Pošlu SZ
5
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Franta Kučera kdy Dnes v 12:24:56 »
To je nepatřičná zkratka. Fyzické objekty většinou mají identitu, ta se nemění. A jejich stav se v čase může měnit (jinak by to byla konstanta), ale ten stav samotný ("otisk objektu") bude hodnotou, která je immutable, že? Nebo naopak: modifikace nějakého atributu objektu vede ke změně jeho stavu (to asi souhlasí), ale identita je zachována.

Ale asi souhlas s tím, že čím víc se vzdalujeme od matematiky (kde se pracuje s immutable hodnotami) k fuzzy reálnému světu, tím míň je funkcionální přístup přirozený.
Ta identita je jen naše abstrakce. Při bližším pohledu to drhne (např. Theseova loď nebo dědečkova sekera).

A i ten "fyzický objekt" je naše škatulka, navíc kapku neostrá.

Směřuju k tomu, že když o něčem mluvíme, tak obvykle žonglujeme s abstraktními immutable objekty, které existují leda tak v nějakém paralelním myšlenkovém nebo platonickém světě. Mapování na nějaké immutable reprezentace není nějaká matematická specialitka, děláme to úplně běžně že to ani nevnímáme.

Ano, identita je abstrakce, přesně tak. Umožňuje nám pracovat s "objekty", které se z fyzikálního hlediska mohou měnit. Jak píšeš a budu parafrázovat: identita "Jiří Havel" bezpochyby jako reprezentace objektu existuje, má mnoho referencí uložených jinde (pošta Ti doručí dopis, úřad Tě dokáže zpárovat - tedy většinou), ale třeba na úrovni molekul/atomů je to naprosto jinej objekt, než v době narození. Nicméně identita stále existuje.

Tak ono záleží jak moc chceme slovíčkařit a ponořit se do (z hlediska softwaru nepodstatných) detailů. Např. ty molekuly vody, ze kterých se nějaký objekt včera skládal, můžou být dneska už úplně někde jinde a patřit k jinému objektu. Kde je teď ta identita? V tom původním objektu nebo tam, kam odešla ta voda?

Ale pro potřeby návrhu softwaru je účelnější se na to dívat z nějaké přirozenější a člověku bližší perspektivy. Když někdo orazítkuje papír, tak se jeho stav změnil (nebudu si hrát na to, že dokument je pořád stejný, jen se v jeho blízkosti zrovna vyskytují molekuly barvy; nebo že v mojí představě je pořád dokument neorazítkovaný, protože jsem ho viděl naposledy včera a pamatuji si ho tak). Když se do auta natankuje benzín, tak se změní jeho stav, když se s ním jezdí, tak se mění stav tachometru… Když tam vyměním motor, tak to pořád považuji za to samé auto… Tohle jsou věci, které mne z pohledu informačního systému zajímají a které má smysl evidovat. Ten obraz reálného světa v počítači je z principu nedokonalý – jen aproximace/podmnožina zvolená tak, aby to dobře sloužilo danému účelu. V databázi si můžu historizovat předchozí stavy a v případě potřeby se na ně můžu dívat. Ale v naprosté většině případů mne zajímá aktuální stav a ne nějaká stará kopie. Pokud s tím chci v jednu chvíli pracovat z více vláken, tak to musím ve vhodnou chvíli rozkopírovat, nebo zamknout nebo obalit třídou která má jen gettery a ne settery (+ ty gettery budou obalovat i vnořené objekty). Ale to jsou technikálie. Z hlediska analýzy a návrhu eviduji nějaká měnící se data. U projektů, na kterých pracuji, se většinou v databázi vše historizuje, skoro nic se nemaže a záznamy spíš jen přibývají – to má blíž k těm neměnným objektům – ale i tam se někdy stavy mění (např. se nastaví validTo, ukončí platnost nebo se změní aktuální zůstatek - byť ty historické jinde zůstanou). Hlavně jsou ale obory a projekty, kde je zvykem ta data i v databázi vesele přepisovat a udržovat tam jen aktuální stav (a historizace se buď nedělá vůbec nebo se ukládá někam bokem pro záznam).

Trochu se omlouvám za to rýpnutí do funkcionální víry ale nedalo mi to :-) Ona je to svým způsobem úžasná věc, čistá, matematicky dokonalá. Jen to praktické využití trochu drhne (např. Lisp a Scheme úplně čisté nejsou; Haskell čistý je, jenže monády jsou utrpení a hlavně pak člověk zjistí, že velká část aplikace je právě o těch vedlejších efektech). Na jedné straně jsou analytici a uživatelé, kteří uvažují a mluví o měnících se objektech a koncept „immutable“ je jim cizí. A na druhé straně máme hardware – hodnoty registrů procesoru se mění, volají se instrukce, program/procesor obdělává paměť. Vše je proměnlivé a uprostřed toho si funkcionální programátor snaží konstruovat nějaký svůj dokonalý svět.

Nechci to úplně zatracovat, nějaké využití to má – hlavně tam, kde se řešená úloha blíží matematice. Ale došel jsem k tomu, že pro většinu softwaru lépe slouží „nečisté“ multiparadigmatické jazyky, kde toho můžu psát (asi) většinu objektově, něco procedurálně/funkcionálně, něco deklarativně.
6
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Jiří Havel kdy Dnes v 12:24:26 »
Pokud objekt osoba zná svou váhu, tak je lepší osoba.GetVaha(). Odděluje se dotaz a vykonání, takže metoda ZvážitSe() nemá nic vracet, jen měnit vnitřní stav objektu. Tohle se odděluje proto, že při každém dalším volání ZvážitSe by se to počítalo znovu a možná s jiným výsledkem. Zásadně se odděluje část vykonání něčeho a vracení výsledku.
Pokud metoda váhy vrací pokaždé jiný výsledek, tak to znamená, že se stav té osoby mění. Takže by se měla měnit i hodnota vracená z GetVaha. Je třeba řešit aby se správně aktualizovala ta uložená hodnota.

Pokud objekt osoba svou váhu znát nepotřebuje, tak je lepší to zvazitSe. Protože Osobě odpadá starost s udržováním aktuální váhy.
7
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Tomáš Crhonek kdy Dnes v 12:09:05 »
Ale co třeba takové:
Kód: [Vybrat]
vaha.zvazit(osoba)
osoba.zvazitSe(vaha)
Je něco z toho zjevně dobře nebo zjevně špatně?

Pokud objekt osoba zná svou váhu, tak je lepší osoba.GetVaha(). Odděluje se dotaz a vykonání, takže metoda ZvážitSe() nemá nic vracet, jen měnit vnitřní stav objektu. Tohle se odděluje proto, že při každém dalším volání ZvážitSe by se to počítalo znovu a možná s jiným výsledkem. Zásadně se odděluje část vykonání něčeho a vracení výsledku.

Stejně tak předávat váze objekt Osoba je často kravina. Ta metoda může být součástí osoby nebo získaná přes implementaci interface (třeba Golang) nebo přes dědění (Java, C++). V Golangu se ani neřeší interface (jeho jméno), prostě stačí definovat jeho metody a objekt může mít implementováno tolik rozhraní, kolik je potřeba.

8
Bazar / Re:Prodám outdoor kabinet 380V/230V PDU/AC/DC HVAC
« Poslední příspěvek od Petr Krčmář kdy Dnes v 11:51:14 »
Dobrý den, sekce bazar je určena pro soukromé inzeráty, ne pro propagaci byznysu. Předpokládám, že se vám z domácích zásob doma neválí 150 kusů stejného výrobku. Prosím, takové inzeráty sem nepatří a nevkládejte je sem. Díky za pochopení.
9
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Kit kdy Dnes v 11:50:04 »
Ona jakákoliv serializace bude v principu narušovat zapouzdření, jinak nemůže fungovat. Je jen otázka, jestli to není zapouzdřené až na úrovni toho xml, nebo už někdy dřív.
Porušení zapouzdření je to v případě, kdy odhalují vnitřní strukturu objektu. Serializace může být na vnitřní struktuře nezávislá - poskytuje nějakou reprezentaci objektu v požadovaném formátu.
10
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Franta Kučera kdy Dnes v 11:43:59 »
Spousta těch objektů žádný protějšek v reálném světě nemá a jde čistě o konstrukt programátora… Nicméně tady bychom mohli najít třeba paralelu mezi tlačítkem na obrazovce a fyzickým tlačítkem. Ale ani to fyzické tlačítko není úplně pasivní. Zrovna co se týče zobrazení, tak to tlačítko samo nějak ovlivňuje světlo, které na něj dopadá (některé vlnové délky pohltí, jiné odrazí, některé třeba propustí skrz), a tím vytváří ten obraz. Takže to, že se tlačítko samo o sobě kreslí (místo aby se nechalo kreslit) dává smysl.* Jde ale právě o tu kanonickou reprezentaci, která je jenom jedna – kreslí se to právě jedním způsobem, negeneruje to PNG, JPEG a X dalších formátů, neobsahuje to kód kreslení pro X11, Wayland, SDL, OpenGL atd. Kreslí to např. na nějaké abstraktní plátno definované tím GUI frameworkem.
Tohle je dost blbý přístup i když potřebuju řešit subsurface scattering v tom plastu. Ve chvíli, kdy jen potřebuju vidět tlačítko, už je to naprosto zcestné.

Začíná to znít jako racionalizace toho, že cpete mutable stavy i tam, kam se vůbec nehodí. Doufám, že se v tomhle pletu.

Sice se tu diskutuje obojí, ale jsou to mimoběžná témata, řekl bych. Rozhodně nebylo záměrem tohoto komentáře podporovat nebo vyvracet nějaký názor na neměnné objekty.

Na neměnném objektu můžu mít metodu, která vyrobí konkrétní formát, stejně jako tam můžu mít metodu, která poskytne tu kanonickou reprezentaci. Totéž na objektu jehož stav se v čase mění.
Stran: [1] 2 3 ... 10