Přechod z Javy na Rust. Ano či ne?

[Franta Kučera]

Kód: [Vybrat]

vaha.zvazit(osoba)
osoba.zvazitSe(vaha)
Oboji je spatne. Melo by to byt akce::zvazit(osoba, vaha) - a je to. Osoba nemusi znat nic o vaze, a vaha muze umet vazit treba i zvirata nebo mouku.

Cele OOP je do jiste miry divne, nuti nas vazat akce na konkretni objekty, ktere by klidne mohly byt naprosto nezavisle.

Jenže pak zjistíš, že těch postupů nebo metod vážení je víc, není to jen jedna univerzální akce zvážit(). Takže můžeš mít např. rozhraní PostupVážení s metodou zvážit(Osoba, Váha) a několik alternativních implementací tohoto rozhraní. Ta PostupVážení může mít ještě nějakou parametrizaci (její součástí může být i ta Váha – a pak voláš jen zvážit(Object)).

Objektové jazyky jsou asi nejflexibilnější – byť s jinou syntaxí, v nich můžeš realizovat to, co jinde. Statická metoda, která vrací hodnotu je funkce. Statická metoda, která má jen (vstupní/výstupní) parametry, je procedura. A např. návrhový vzor továrna je funkce, obvykle používaná jako funkce vyššího řádu. Typicky ji někam předáváš jako parametr nebo ti ji někdo vrací jako návratovou hodnotu. A oproti jiným paradigmatům umožňuje OOP spojit více funkcí/metod, které k sobě logicky patří, plus související data, do jednoho objektu.

(samozřejmě to má svoje úskalí, viz ten můj odkazovaný článek, a není dobré se do toho vrhat bezhlavě, trochu krotit prvotní nadšení a držet kreativitu na uzdě, ale to platí všude)

[Reklama]

[Franta Kučera]

Tohle ale záleží na konkrétním programu. Kevlin Henney (https://en.wikipedia.org/wiki/Kevlin_Henney) doporučuje každý program dělat maximálně konkrétní, tedy pro tiskárnu je normální mít datové typy jako ink, paper, book apod. Je nevhodné vytvářet abstraktní metody, které umí vážit slona, když potřebuju jen znát hmotnost inkoustu. Tiskárna ví, kolik ho potřebuje a datový objekt typu ink může mít metodu GetVolume(). Nebo ještě lépe, mít kontejner pro inkousty a o každém ví, kolik jaké barvy tam je.

Jak kde. Postupem času jsem došel k tomu, že 1) implementaci, která je skrytá uvnitř, je většinou dobré dělat co nejjednodušší, nedělat overengineering, nevyrábět tam za každou cenu X objetků nebo abstraktních rozhraní, když stačí pár obyčejných metod, pár bloků kódu. Protože tyhle implementační detaily můžeš kdykoli přepsat a udělat je složitější nebo „pořádně objektově“. Ale u 2) veřejného rozhraní bys měl ten návrh udělat robustní už na začátku a myslet (v nějakém rozumném horizontu) i na budoucí vývoj a obecnost, univerzálnost. Protože veřejné API bys měl měnit co nejméně a hlavně zpětně kompatibilně (pokud nechceš naštvat všechny kolem sebe).

Více jsem to rozepsal v Rozlišování veřejného API a interních rozhraní.

[Tomáš Crhonek]

Jak kde. Postupem času jsem došel k tomu, že 1) implementaci, která je skrytá uvnitř, je většinou dobré dělat co nejjednodušší, nedělat overengineering, nevyrábět tam za každou cenu X objetků nebo abstraktních rozhraní, když stačí pár obyčejných metod, pár bloků kódu. Protože tyhle implementační detaily můžeš kdykoli přepsat a udělat je složitější nebo „pořádně objektově“. Ale u 2) veřejného rozhraní bys měl ten návrh udělat robustní už na začátku a myslet (v nějakém rozumném horizontu) i na budoucí vývoj a obecnost, univerzálnost. Protože veřejné API bys měl měnit co nejméně a hlavně zpětně kompatibilně (pokud nechceš naštvat všechny kolem sebe).

Více jsem to rozepsal v Rozlišování veřejného API a interních rozhraní.

Jo, v tomto se shodujeme. Já jsem reagoval na tu univerzální váhu akce::zvazit(osoba, vaha) - tohle je kravina, proč by metoda zvážit měla dostat ještě další obecnou metodu váha? (A prosím, programujme pouze anglicky.)

To, že se veřejné API nemění se nemusíme ani bavit, ale tady je přece diskuse o implementaci. Všechny jazyky mají něco jako interface, golang má bohaté datové typy z možností si jich udělat kolik potřebuju, k tomu definovat metody rozhraní a potom si to každý může naimplementovat jak potřebuje. Stačí dodržet signaturu rozhraní a typy (ty jsou definované v předávaných parametrech rozhraní). Možná mám moc rád golang, ale tohle je přesně to, proč mám rád i PostgreSQL a jeho bohatství datových typů a jejich omezení (referenční integrita, constraints apod.). Prostě teplota v Kelvinech je vždy větší než nula apod.

[Jiří Havel]

Objektové jazyky jsou asi nejflexibilnější – byť s jinou syntaxí, v nich můžeš realizovat to, co jinde...

Tohle ale platí pro úplně všechny výpočetně úplné jazyky. Rozdíl je jen v tom, jak je ta jiná syntaxe ukecaná, (ne)pohodlná nebo náchylná k chybám a podobně.

[Jožka Niemand]

Objektové jazyky jsou asi nejflexibilnější – byť s jinou syntaxí, v nich můžeš realizovat to, co jinde.

Nejflexibilnější jsou jazyky s otevřenou minimalistickou syntaxí, v nichž si mohu dotvořit, co potřebuji - jako LISP, FORTH, TCL... Ani jeden z nich nebyl vytvořen jako objektový, v žádném z nich ale není problém objektový systém dotvořit, když bez něj někdo nemůže žít (což se i stalo; obzvláště CLOS je podle mě nejméně o level lepší objektový systém, než jaký nabízí C++, C# nebo Java). Ale jazyky tohoto typu IMHO objektové nadstavby nepotřebují, protože samy o sobě umožňují vytváření tak silných výrazových prostředků, jaké si jen autor programu přeje a potřebuje k řešení svého problému, takže proč se omezovat na objekty.

[Reklama]

[Radek Miček]

Objektové jazyky jsou asi nejflexibilnější – byť s jinou syntaxí, v nich můžeš realizovat to, co jinde.

Nejflexibilnější jsou jazyky s otevřenou minimalistickou syntaxí, v nichž si mohu dotvořit, co potřebuji - jako LISP, FORTH, TCL... Ani jeden z nich nebyl vytvořen jako objektový, v žádném z nich ale není problém objektový systém dotvořit, když bez něj někdo nemůže žít (což se i stalo; obzvláště CLOS je podle mě nejméně o level lepší objektový systém, než jaký nabízí C++, C# nebo Java). Ale jazyky tohoto typu IMHO objektové nadstavby nepotřebují, protože samy o sobě umožňují vytváření tak silných výrazových prostředků, jaké si jen autor programu přeje a potřebuje k řešení svého problému, takže proč se omezovat na objekty.

Mám pocit, že pro jazyky s multimetodami nikdy nevznikla efektivní implementace. Nebo ano?

[Tomáš Crhonek]

Objektové jazyky jsou asi nejflexibilnější – byť s jinou syntaxí, v nich můžeš realizovat to, co jinde.

Nejflexibilnější jsou jazyky s otevřenou minimalistickou syntaxí, v nichž si mohu dotvořit, co potřebuji - jako LISP, FORTH, TCL... Ani jeden z nich nebyl vytvořen jako objektový, v žádném z nich ale není problém objektový systém dotvořit, když bez něj někdo nemůže žít (což se i stalo; obzvláště CLOS je podle mě nejméně o level lepší objektový systém, než jaký nabízí C++, C# nebo Java). Ale jazyky tohoto typu IMHO objektové nadstavby nepotřebují, protože samy o sobě umožňují vytváření tak silných výrazových prostředků, jaké si jen autor programu přeje a potřebuje k řešení svého problému, takže proč se omezovat na objekty.

Mám pocit, že pro jazyky s multimetodami nikdy nevznikla efektivní implementace. Nebo ano?

Nevím přesně co tím myslíš. Psal o tom pan Tišnovský v roce 2016 a jazyku Clojure. Podle popisu to vypadá na podobnou věc, jako je v golangu tzv. func receiver. Tedy možnost si připsat metodu do objektu syntaxí

(object)Method(args)

Takto se do object dostane další metoda v rámci aktuální package. Každý package si může definovat jinou vlastní metodu pro sdílený objekt.

[Radek Miček]

Objektové jazyky jsou asi nejflexibilnější – byť s jinou syntaxí, v nich můžeš realizovat to, co jinde.

Nejflexibilnější jsou jazyky s otevřenou minimalistickou syntaxí, v nichž si mohu dotvořit, co potřebuji - jako LISP, FORTH, TCL... Ani jeden z nich nebyl vytvořen jako objektový, v žádném z nich ale není problém objektový systém dotvořit, když bez něj někdo nemůže žít (což se i stalo; obzvláště CLOS je podle mě nejméně o level lepší objektový systém, než jaký nabízí C++, C# nebo Java). Ale jazyky tohoto typu IMHO objektové nadstavby nepotřebují, protože samy o sobě umožňují vytváření tak silných výrazových prostředků, jaké si jen autor programu přeje a potřebuje k řešení svého problému, takže proč se omezovat na objekty.

Mám pocit, že pro jazyky s multimetodami nikdy nevznikla efektivní implementace. Nebo ano?

Nevím přesně co tím myslíš. Psal o tom pan Tišnovský v roce 2016 a jazyku Clojure. Podle popisu to vypadá na podobnou věc, jako je v golangu tzv. func receiver. Tedy možnost si připsat metodu do objektu syntaxí

(object)Method(args)

Takto se do object dostane další metoda v rámci aktuální package. Každý package si může definovat jinou vlastní metodu pro sdílený objekt.

Měl jsem na mysli rychlostí. Že volání multimetod v CLOS není (myslím si) tak rychlé jako v C++ (kde je dispatch jen podle jednoho argumentu).

[anonacct]

Já jen použil příklad co tu byl, kdybych měl vytvořit vlastní tak by zněl takto:

```
struct Point {
  double x, y;
};
```

Chci vůbec mít member funkce? Já třeba preferuju `distance(p1, p2)` než `p1.distance(p2)`. To samé když vidím třeba `a.dot(b)`, atd... přijde mi to až přehnané API navrhovat takto.