Ideálny programovací jazyk

[Jiří Havel]

Co mě tu hlavně mate je, že v tomhle případě by se mohlo jak automaticky boxovat tak unboxovat. A ani přečtení dokumentace mi neobjasnilo, co by mělo mít přednost. Jak boxování tak unboxování se má dělat v případě, že se předává parametr nebo přiřazuje do proměnné. Na základě čeho se rozhodne, že se tady má zrovna unboxovat?

U aritmetických operátorů boxování nepřichází v úvahu, dostali bychom zase jen nepřeložitelný kód. No a u komparačních operátorů je za prvé rozumné dělat to stejně, a zda druhé by boxování bylo s prominutím padlé na hlavu, protože je čistě věcí kompilátoru, jakou referenci vám tam vrátí – a když ta reference mohla právě teď vzniknout, nedává smysl ji porovnávat na rovnost s jinou referencí. Porovnávat reference má smysl tam, kde už je máte z dřívějška uložené (třeba klasická zarážka při hledání v poli).

Takže je to speciální ad-hoc pravidlo jak porovnávat boxované a neboxované věci? Nevyplývá to z nějakého obecnějšího pravidla pro řešení podobných neurčitých situací? Dávalo by mi to smysl i pro výběr přetížených metod, ale tam to evidentně funguje jinak. Čím dál tím lepší...

Je to totiž Havel!

Nic mi nedokážete, všechno popřu.

[Reklama]

[BoneFlute]

Tuhle variantu už jste vy naimplementoval pro oba jazyky, a – světe div se – je to jak jsem psal, vychází to v obou jazycích stejně. Dovolte, abych z vašeho kódu ty dva řádky vypíchl:

No, nevychází, že 

Kód: [Vybrat]

System.out.println(a.equals(b)); // true
print (a == b) # True – používá se zde přetížený operátor ==


Přesně tak. Čitelnější to být nemůže.

Java, int: ekvivalence, použije se ==. Porovnání identity, zde popravdě netuším.
Java, objekt: ekvivalence, použije se operátor/metoda equals(). Porovnání identity, použije se operátor ==
Python, int: ekvivalence, použije se operátor ==. Porovnání identity, použije se operátor is.
Python, objekt: ekvivalence, použije se operátor ==, který se interně převede na __eq__. Porovnání identity, použije se operátor is.

A takhle, jak je to v Pythonu to mám rád.

Popravdě, zase si moc nefanděte. Já to píšu jen tak jako cvičení. Opravdu si nedělám naděje vám cokoliv vysvětlit 

[BoneFlute]

K tématu:

Uvažoval jsem, že některé vlastnosti OOP se moc neosvědčili. Dědičnost a abstraktní třídy, vzor template method. Místo toho mixiny, nebo traity. Tedy znovupoužitelné fragmenty kódu, bez zanášení typu. Jestli ponechat dědičnost na úrovni rozhraní, nebo ani v tomto případě ne?

[Filip Jirsák]

Takže je to speciální ad-hoc pravidlo jak porovnávat boxované a neboxované věci? Nevyplývá to z nějakého obecnějšího pravidla pro řešení podobných neurčitých situací? Dávalo by mi to smysl i pro výběr přetížených metod, ale tam to evidentně funguje jinak. Čím dál tím lepší...

Ve specifikaci je to speciální pravidlo, když ho budu parafrázovat „pokud jsou oba operandy číslo nebo je jeden operand číslo a druhý je převoditelný na číslo (unboxováním), nejprve se převoditelný typ převede na číslo“. U booleovských hodnot je to podobné.

U metod se vybírá co nejmenší počet boxování/unboxování, a pokud by z toho vyšlo víc metod, je to kompilační chyba (např. dvě metody se dvěma parametry, jedna s malými inty a druhá s velkými Integery a volalo by se to s jedním malým a druhým velkým).

Zkrátka se to chová tak, jak by člověk intuitivně očekával. A na tyhle nuance člověk narazí velmi výjimečně, a pokud by se to náhodou stalo, tak nebude spoléhat na automatiku a udělá ten un/boxing ručně. Teoreticky by z toho posloupností špatných událostí mohla vzniknout chyba, ale až tyhle chyby budou ty nejčastější chyby v softwaru, budeme mít bezchybný software.

[Mirek Prýmek]

Jestli ponechat dědičnost na úrovni rozhraní, nebo ani v tomto případě ne?

Co dobrého a netriviálního by podle tebe přineslo to mít? Já mám pocit, že dědičnost kdekoli dělá víc škody než užitku*.

Mně by se spíš líbilo to nahradit pěkným, stručným skládáním. Je dost škoda, když je v některých jazycích potřeba celé API vloženého objektu znovu zopakovat na tom vnějším (mám matný pocit, že to tak má někde Rust, ale přesně si to teď nevybavím).

----
* dědičnost má imho technické a filosofické problémy. Dědění tříd má oba typy problémů a relativně velký přínos, dědění interfejsů má spíš jenom filosofické problémy a přínos imho celkem malý. Takže bych se s tím nesral a vyhodil oboje

[Reklama]

[Filip Jirsák]

No, nevychází, že 
Přesně tak. Čitelnější to být nemůže.

Jasně, v prvním případě hodnota pro pravdivý výrok, v druhém případě hodnota pro pravdivý výrok. V tom je takový rozdíl… Já už vážně nevím, co tam vidíte za rozdíl. Jako ano, jednou je tam true a po druhé True, jednou malé „t“ a podruhé velké „T“. Ale důvod, proč se liší velikost toho T snad chápete, ne?

Ano, přesně jak jsem předpovídal, následuje nářek, že jsem sice celou dobu psal o operátoru ==, ale to jsem určitě udělal naschvál, aby si BoneFlute myslel, že píšu o ekvivalenci nebo identitě. Zákeřně jsem tam čtyřikrát napsal slovo „operátor, dvakrát == a jednou __eq__, a ještě zákeřnější bylo, že jsem tam slovo „identita“ neuvedl ani jednou. Přeci mi muselo být nad slunce jasné, že si BoneFlute bude myslet, že celou dobu píšu o identitě. Teda ale fuj, že se nestydím.

Java, int: ekvivalence, použije se ==. Porovnání identity, zde popravdě netuším.
Java, objekt: ekvivalence, použije se operátor/metoda equals(). Porovnání identity, použije se operátor ==
Python, int: ekvivalence, použije se operátor ==. Porovnání identity, použije se operátor is.
Python, objekt: ekvivalence, použije se operátor ==, který se interně převede na __eq__. Porovnání identity, použije se operátor is.

Flamewar je sice divná zábava, ale zábava je to jenom dokud ho vedete s chytrými lidmi. Takže BoneFlute, mějte se dobře, naše konverzace tímto končí.

[Jiří Havel]

Tak tenhle příspěvek mě moc neuklidnil.

Takže je to speciální ad-hoc pravidlo jak porovnávat boxované a neboxované věci? Nevyplývá to z nějakého obecnějšího pravidla pro řešení podobných neurčitých situací? Dávalo by mi to smysl i pro výběr přetížených metod, ale tam to evidentně funguje jinak. Čím dál tím lepší...

Ve specifikaci je to speciální pravidlo, když ho budu parafrázovat „pokud jsou oba operandy číslo nebo je jeden operand číslo a druhý je převoditelný na číslo (unboxováním), nejprve se převoditelný typ převede na číslo“. U booleovských hodnot je to podobné.

U metod se vybírá co nejmenší počet boxování/unboxování, a pokud by z toho vyšlo víc metod, je to kompilační chyba (např. dvě metody se dvěma parametry, jedna s malými inty a druhá s velkými Integery a volalo by se to s jedním malým a druhým velkým).

Zkrátka se to chová tak, jak by člověk intuitivně očekával. A na tyhle nuance člověk narazí velmi výjimečně, a pokud by se to náhodou stalo, tak nebude spoléhat na automatiku a udělá ten un/boxing ručně. Teoreticky by z toho posloupností špatných událostí mohla vzniknout chyba, ale až tyhle chyby budou ty nejčastější chyby v softwaru, budeme mít bezchybný software.

Když jsem to četl, tak ve mně hrklo, protože co nejmenší počet boxování a unboxování mi přijde jako další neintuitivní past. Naštěstí to není pravda. Když jsem to zkoušel tak mě překladač seřval vždycky. Aspoň v něčem se teda Java chová tak, jak bych čekal.

[Filip Jirsák]

Mně by se spíš líbilo to nahradit pěkným, stručným skládáním. Je dost škoda, když je v některých jazycích potřeba celé API vloženého objektu znovu zopakovat na tom vnějším (mám matný pocit, že to tak má někde Rust, ale přesně si to teď nevybavím).

Takže nakonec to přece jenom bude JavaScript? ;-) (Spread operátor na objektových literálech v ECMAScript 2018.)

[Cikáda]

Flamewar je sice divná zábava, ale zábava je to jenom dokud ho vedete s chytrými lidmi. Takže BoneFlute, mějte se dobře, naše konverzace tímto končí.

Jsem rád, že tu zůstanu sám s chytrýma.. ale klidně zas někdy přijď. 

[Filip Jirsák]

Když jsem to četl, tak ve mně hrklo, protože co nejmenší počet boxování a unboxování mi přijde jako další neintuitivní past. Naštěstí to není pravda. Když jsem to zkoušel tak mě překladač seřval vždycky. Aspoň v něčem se teda Java chová tak, jak bych čekal.

Aha, ono se rozlišuje jenom žádné (un)boxování, nějaké (un)boxování. Vždyť jsem říkal, že se s tím v praxi nikdo nikdy nepotká.

[Mirek Prýmek]

Takže nakonec to přece jenom bude JavaScript? ;-) (Spread operátor na objektových literálech v ECMAScript 2018.)

JS není špatný v principu, ale v tom, že se tam doprasilo co mohlo. Lua je "JS done right", nezaznamenal jsem, že by s ní kdokoli měl problém. Ne že by to byl jazyk, ve kterém bych nějak zvlášť chtěl dělat, ale je to jazyk hodný respektu.

[BoneFlute]

Jestli ponechat dědičnost na úrovni rozhraní, nebo ani v tomto případě ne?

Co dobrého a netriviálního by podle tebe přineslo to mít? Já mám pocit, že dědičnost kdekoli dělá víc škody než užitku*.

To úplně tak promyšlený nemám. Jednou jsem si hrál s něčím takovým:
Article
ArticleIdentification <- Article
ArticleSlugIdentification <- ArticleIdentification
ArticleIdIdentification <- ArticleIdentification
ArticleFullIdentification <- ArticleIdentification
ArticlePreview <- Article, ArticleIdentification
ArticleDetail <- Article, ArticleIdentification
ArticleModify <- Article, ArticleIdentification, Command
ArticleCreate <- Article, Command

Smysl to dávalo, neměl jsem možnost to pořádně prozkoumat praxí. A dráždí mě tam ta evidentní ukecanost.

Mně by se spíš líbilo to nahradit pěkným, stručným skládáním. Je dost škoda, když je v některých jazycích potřeba celé API vloženého objektu znovu zopakovat na tom vnějším (mám matný pocit, že to tak má někde Rust, ale přesně si to teď nevybavím).

Ano. Psal jsem o traitech a mixinech. To považuji za vhodného kadidáta.

[BoneFlute]

Takže nakonec to přece jenom bude JavaScript? ;-) (Spread operátor na objektových literálech v ECMAScript 2018.)

JS není špatný v principu, ale v tom, že se tam doprasilo co mohlo. Lua je "JS done right", nezaznamenal jsem, že by s ní kdokoli měl problém. Ne že by to byl jazyk, ve kterém bych nějak zvlášť chtěl dělat, ale je to jazyk hodný respektu.

+1

[Jiří Havel]

K tématu:

Uvažoval jsem, že některé vlastnosti OOP se moc neosvědčili. Dědičnost a abstraktní třídy, vzor template method. Místo toho mixiny, nebo traity. Tedy znovupoužitelné fragmenty kódu, bez zanášení typu. Jestli ponechat dědičnost na úrovni rozhraní, nebo ani v tomto případě ne?

Jop, type classy z Haskellu a traity z Rustu jsou asi nejlepší přístup k polymorfismu, co jsem zatím potkal. Koncepty v novém C++ se tím hodně inspirovaly, takže vypadají taky až překvapivě dobře.

Dědičnost bych nezavrhoval úplně, ale souhlasím že pro intuitivní implementaci vztahu "is-a" se moc nehodí. I když se tak často prezentuje.

[BoneFlute]

Dědičnost bych nezavrhoval úplně, ale souhlasím že pro intuitivní implementaci vztahu "is-a" se moc nehodí. I když se tak často prezentuje.

Na vztahy jsem uvažoval v duchu Prologu. Ale zatím jsem nic nevymyslel :-)