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 Jožka Niemand kdy Dnes v 10:58:49 »
To je dost rozdíl oproti té serializaci do různých formátů (počet těch formátů je neomezený a předem neznámý).
No a v objektovém návrhu, jak ho chápu já, by naopak spíše objekt toužící po serializaci jiného objektu (exportu do jiného formátu...) poskytl takovému objektu objekt, pomocí kterého si to ten inkriminovaný objekt zařídí sám. Tím netvrdím, že opačný přístup je chybný, spíše bych řekl, že ve skutečnosti jen není objektový, protože narušuje zapouzdření. Ve skutečnosti může být (a také asi bude) jednodušší a efektivnější - znalost nějakých vnitřních detailů objektu může spoustu věcí usnadnit, naopak - blackboxing "za každou cenu" může vést k neřešitelným (nepředvídatelným) situacím při návrhu rozhraní. Ale to se dostáváme k samotné filosofické otázce, zda tedy vůbec OOP.
2
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Kit kdy Dnes v 10:52:16 »
Nicméně v tom příkladu šlo o tu logiku, který objekt je aktivní a který pasivní a kde se nachází implementace. Jde třeba o různé ukládání nebo načítání – ať už do různých souborových formátů nebo třeba do databáze nebo odeslání na po síti. Ve většině případů považuji za špatný návrh to, aby ten datový objekt měl takovou metodu. Většinou patří spíš do jiného objektu, který se o de/serializaci příslušného formátu (PNG, XML atd.) nebo obsluhu příslušného úložiště a správu spojení stará. Je to pružnější návrh, který umožňuje přidávat další formáty a úložiště (i jiným autorům) a nezanáší to rozhraní toho objektu a nezvyšuje to komplexitu jeho implementace (v něm je jen metoda a kód pro vrácení nebo načtení nějaké kanonické implementace třeba RGB bitmapy, zatímco implementace jednotlivých kodeků je jinde).
Pak ovšem musíš vnitřní stav toho objektu zpřístupnit vnějšímu světu (pro serializaci a deserializaci), což porušuje princip zapouzdření.

V tomto smyslu porušují zapouzdření všechny gettery a settery. Přesto je kdekdo používá.
3
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Jiří Havel kdy Dnes v 10:49:00 »
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.
4
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Jiří Havel kdy Dnes v 10:40:52 »
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.
5
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Filip Jirsák (forum) kdy Dnes v 10:32:04 »
Ze je potreba selsky rozum, abych dovedl poznat, ktery objekt je v danem kontextu aktorem, ktery je prosty objekt, se kterym aktor manipuje.
Vidle.naberHnuj(hnuj) je spravny pristup
Hnuj.naskocNaVidle(vidle) je magorina.
Tohle je ovšem čistě záležitost přirozeného jazyka, ve kterém to popisujete. A nemyslím si, že by implementace v kódu měla být až tak závislá na jazyce, ve kterém máte popsané zadání.

Ono to i česky můžete napsat Hnuj.naberSeNa(vidle), a už to taková magořina není. I když sloveso nabrat se obvykle ve zvratné formě nepoužíváme.

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ě?

Nicméně v tom příkladu šlo o tu logiku, který objekt je aktivní a který pasivní a kde se nachází implementace. Jde třeba o různé ukládání nebo načítání – ať už do různých souborových formátů nebo třeba do databáze nebo odeslání na po síti. Ve většině případů považuji za špatný návrh to, aby ten datový objekt měl takovou metodu. Většinou patří spíš do jiného objektu, který se o de/serializaci příslušného formátu (PNG, XML atd.) nebo obsluhu příslušného úložiště a správu spojení stará. Je to pružnější návrh, který umožňuje přidávat další formáty a úložiště (i jiným autorům) a nezanáší to rozhraní toho objektu a nezvyšuje to komplexitu jeho implementace (v něm je jen metoda a kód pro vrácení nebo načtení nějaké kanonické implementace třeba RGB bitmapy, zatímco implementace jednotlivých kodeků je jinde).
Pak ovšem musíš vnitřní stav toho objektu zpřístupnit vnějšímu světu (pro serializaci a deserializaci), což porušuje princip zapouzdření.
6
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Zdenek Tomes kdy Dnes v 10:26:53 »
Fyzické objekty nikdy nejsou „immutable“ (i když by si to vyznavači funkcionální víry přáli :-). Ty objekty mají stav, který se v čase mění.

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ý.
7
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Franta Kučera kdy Dnes v 10:23:06 »
P.S. Ještě k té paralele se světlem: Tlačítko nějak formuje světlo (pohlcuje, odráží, propouští). To je ta kanonická reprezentace. Ale jestli se to propuštěné nebo odražené světlo promítne na bílou stěnu, plátno s nějakou texturou, film nebo snímač fotoaparátu atd. to už to tlačítko neřeší – to je kompetence někoho jiného, stejně tak kdo a jak na to tlačítko bude svítit. Podobně v počítači: třída tlačítka sice ovlivňuje jak ten obraz bude vypadat, ale jestli se vykreslí na X11, do OpenGL nebo třeba do PDF, to už řeší někdo jiný.
8
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Franta Kučera kdy Dnes v 10:11:59 »
Nicméně v tom příkladu šlo o tu logiku, který objekt je aktivní a který pasivní a kde se nachází implementace. Jde třeba o různé ukládání nebo načítání – ať už do různých souborových formátů nebo třeba do databáze nebo odeslání na po síti. Ve většině případů považuji za špatný návrh to, aby ten datový objekt měl takovou metodu. Většinou patří spíš do jiného objektu, který se o de/serializaci příslušného formátu (PNG, XML atd.) nebo obsluhu příslušného úložiště a správu spojení stará. Je to pružnější návrh, který umožňuje přidávat další formáty a úložiště (i jiným autorům) a nezanáší to rozhraní toho objektu a nezvyšuje to komplexitu jeho implementace (v něm je jen metoda a kód pro vrácení nebo načtení nějaké kanonické implementace třeba RGB bitmapy, zatímco implementace jednotlivých kodeků je jinde).
To ale nejde takto kategoricky, bez kontextu říci. A to je přesně to, o čem jsem mluvil - past zkušenosti "reálného světa", "selský rozum". Jenže ten občas selhává. Tento selský rozum by nám velel, že např. v nějakém GUI je nějaký painter, který zajišťuje zobrazování jednotlivých oken (jako Screen.paint(window)) - a opravdu tak něco takového může být. Ale z praktického hlediska window rozumí nějaké zprávě typu drawOn, kterou nakonec zpětně pošle ten painter tomu oknu, protože ono nejlépe ví, jak se namalovat - tedy nakresli se - což je to "zvěrstvo" typu naskoč si na vidle. Naopak, lpění na modelu z reálného světa by představovalo komplikaci.

Ohledně třeba toho kreslení souhlasím, ale nemyslím si, že bychom byli až tak ve sporu.

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.

To je dost rozdíl oproti té serializaci do různých formátů (počet těch formátů je neomezený a předem neznámý). Ve fyzickém světě: i když fyzické tlačítko nějak nějak samo ovlivňuje dopadající světlo, tak to tlačítko se samo neumí popsat v různých jazycích – musí přijít někdo zvenku a říct česky: „je to červené tlačítko, na kterém je žlutý vykřičník“ – někdo jiný to řekne anglicky, někdo jiný svahilsky atd. Těch jazyků je mnoho a během existence tlačítka mohou klidně vzniknout nové – tlačítko o nich vůbec nemůže a nemá vědět.

Píšu o problému, na který občas narážím v praxi – někdo do objektu zadrátuje nějaké konkrétní exporty nebo operace místo toho, aby to řízení buď úplně obrátil nebo tam dal jen nějaký jeden kanonický tvar / abstraktní operaci. Takový návrh je nepružný a problém je jednak v tom, že je tam zadrátovaná komplexita nějakého konkrétního formátu (a v budoucnu tam lidi budou přidávat další formáty potažmo závislosti na dalších knihovnách a budou nesmyslně navyšovat komplexitu místo toho, aby ty závislosti byly volitelné a někde jinde) a jednak v tom, že nejde přidat další formát, aniž bych měnil kód dané třídy.

*) ono to tedy bývá trochu složitější, protože ty GUI komponenty mívají nějaký model obsahující čistá data a pak pohled – ten model nic nekreslí, ten pohled ano, i když část toho kreslení deleguje ještě na jiné třídy, díky kterým celé to GUI bude mít jednotný vzhled a chování
9
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od balkovic kdy Dnes v 09:56:40 »
2/ většina jazyků lepší nástroj pro reusable kódu jak dědičnost nemá (Java), některé nemají dokonce ani rozhraní (C++) (Překvapivě takový odsuzovaný jazyk jako je PHP ano.)

Dovolím si polemizovať, java má aj lambdy a to je ďalšia možnosť prepoužitelnosti kódu. Potom sú rozhrania s default implementáciami metód, čo sú vlastne traits na javovský spôsob.

Já ti nevím. Lambdy jsou IMHO na něco jiného, a default implemetace metod tak nějak neřeší, že v jedné skupině adaptérů chci tuto implementaci a v druhé skupině jinou. Nemluvě o tom, že je to stále dědění. To je stejně blbě, jak se o tom bavíme.

Keď sa interfacy s default metódami dobre použijú, umožňujú spraviť kompozíciu miesto kitchensink dedenia. A tvrdenie, že funkcionálne programovanie neumožňuje znovupoužiteľnosť kódu, za to by ma prefackali.
10
Bazar / Prodám outdoor kabinet 380V/230V PDU/AC/DC HVAC
« Poslední příspěvek od Kampeak kdy Dnes v 09:54:40 »
Dobrý den,
Nabízím venkovní kabinet.

Cabinet empty-ASSY, EQUIPMENT CABINET (it does include several small components such like breakers, cables, …)
Cabinet (HVAC included), Dantherm (DC Air Conditioner 4000)VICD, HVAC, 4000BTU/HR COOLING CAP, 500W HEATER, 48VDC, VARIABLE SPEED COMPRESSOR AND FAN, CLOSED LOOP COOLING, 29.0X17.3X11.3IN, -40 T0 55C,UL/CUL/ROHS

V případě zájmu prosím se mi ozvěte
Skladem 150 KS

Stran: [1] 2 3 ... 10