Conditional conformance v OOP

Prograt

Conditional conformance v OOP
« kdy: 17. 02. 2018, 22:08:16 »
Koukám teď na Swift a jeho "conditional conformance". Má otázka: v jakých dalších mainstreamových jazycích se vyskytuje? Podle mých skromných znalostí to C++ ani Java nemá, ale neznám moc třeba Rust, Kotlin atd.


Sten

Re:Conditional conformance v OOP
« Odpověď #1 kdy: 17. 02. 2018, 22:38:41 »
Šablony v C++ se takhle chovají, metody se instancují až při použití a syntakticky validní, ale sématicky nevalidní kód se do té doby ignoruje. Takže můžete udělat třeba netříděný kontejner (třeba pole) s metodou sort, která bude vyžadovat operátor porovnání (<) u vnořeného typu. Pokud vytvoříte instanci s typem, který nelze porovnávat, tak překlad selže pouze v případě, že tu metodu použijete.

klokan

Re:Conditional conformance v OOP
« Odpověď #2 kdy: 18. 02. 2018, 01:32:39 »
Kotlin moc neznám. Rust má něco trochu podobného formou autoimplementace traitů (trait v Rustu = protokol ve Swiftu). Zjednodušeně řečeno je možné deklarovat, že cokoli implementuje např. traity Kráva a Prase, případně s dalšími podmínkami ohledně přidružených typů, konstant apod., má automaticky i nějakou výchozí implementaci traitu Debil. V podstatě je to jakási náhrada za tzv. kachní typování, které Rust nemá, sice těžkopádnější, než pravý duck typing jako má např. Go, ale za to je bezpečná, staticky kontrolovatelná a výborně se optimalizuje.

Labrat

Re:Conditional conformance v OOP
« Odpověď #3 kdy: 18. 02. 2018, 01:44:28 »
Kotlin moc neznám. Rust má něco trochu podobného formou autoimplementace traitů (trait v Rustu = protokol ve Swiftu). Zjednodušeně řečeno je možné deklarovat, že cokoli implementuje např. traity Kráva a Prase, případně s dalšími podmínkami ohledně přidružených typů, konstant apod., má automaticky i nějakou výchozí implementaci traitu Debil. V podstatě je to jakási náhrada za tzv. kachní typování, které Rust nemá, sice těžkopádnější, než pravý duck typing jako má např. Go, ale za to je bezpečná, staticky kontrolovatelná a výborně se optimalizuje.
Go taky nemá pravé duck typing (pročež je bezpečné a staticky typované). Ta podmíněná konformita akorát umožňuje flexibilnější a úspornější implementaci protokolů u generických typů (ať už tříd nebo struktur). Ovšem bez higher kinds (viz "vyšší druhy" na Wikipedii) bude typový systém Swiftu stále neúplný.

klokan

Re:Conditional conformance v OOP
« Odpověď #4 kdy: 18. 02. 2018, 07:08:20 »
Myslím, že Go má k pravému duck typingu nejblíže ze statických jazyků. Není ale pravda, že by bylo bezpečné. V tom smyslu jako Rust bezpečné není.

Se Swiftem jsem nikdy nic nedělal, tak mě překvapuje, že ani on nemá typy vyšších druhů. Stejně je na tom Rust a patří to k věcem, které mu bývají vytýkány. Rust si částečně vypomáhá přidruženými typy, což je ale jenom bastl, jak se v některých případech obejít bez vyšších druhů, které by se tam výborně hodily. Je ale spousta věcí, včetně plné podpory monád, které tak doopravdy implementovat nejdou. Je to velká škoda a je zajímavé, že i Swift se rozhodl se takto omezit. Rád bych věděl, co návrhářům moderních jazyků na typech vyšších druhů tolik vadí?


Labrat

Re:Conditional conformance v OOP
« Odpověď #5 kdy: 18. 02. 2018, 12:57:39 »
Myslím, že Go má k pravému duck typingu nejblíže ze statických jazyků. Není ale pravda, že by bylo bezpečné. V tom smyslu jako Rust bezpečné není.

Se Swiftem jsem nikdy nic nedělal, tak mě překvapuje, že ani on nemá typy vyšších druhů. Stejně je na tom Rust a patří to k věcem, které mu bývají vytýkány. Rust si částečně vypomáhá přidruženými typy, což je ale jenom bastl, jak se v některých případech obejít bez vyšších druhů, které by se tam výborně hodily. Je ale spousta věcí, včetně plné podpory monád, které tak doopravdy implementovat nejdou. Je to velká škoda a je zajímavé, že i Swift se rozhodl se takto omezit. Rád bych věděl, co návrhářům moderních jazyků na typech vyšších druhů tolik vadí?
Duck typing je záležitost běhu (runtime), kdežto v Go se všechny typy řeší při kompilaci, je to normální statické typování s rozhraními. Je bezpečné stejně jako Java nebo C++ v tom smyslu, že co projde překladem, nespadne.

Bach

Re:Conditional conformance v OOP
« Odpověď #6 kdy: 18. 02. 2018, 20:25:22 »
Šablony v C++ se takhle chovají, metody se instancují až při použití a syntakticky validní, ale sématicky nevalidní kód se do té doby ignoruje. Takže můžete udělat třeba netříděný kontejner (třeba pole) s metodou sort, která bude vyžadovat operátor porovnání (<) u vnořeného typu. Pokud vytvoříte instanci s typem, který nelze porovnávat, tak překlad selže pouze v případě, že tu metodu použijete.
To je dost podivné chování.

adsfasdfasdfasdf

Re:Conditional conformance v OOP
« Odpověď #7 kdy: 18. 02. 2018, 22:16:35 »
Šablony v C++ se takhle chovají, metody se instancují až při použití a syntakticky validní, ale sématicky nevalidní kód se do té doby ignoruje. Takže můžete udělat třeba netříděný kontejner (třeba pole) s metodou sort, která bude vyžadovat operátor porovnání (<) u vnořeného typu. Pokud vytvoříte instanci s typem, který nelze porovnávat, tak překlad selže pouze v případě, že tu metodu použijete.
To je dost podivné chování.

ale ma to logiku, zkompiluje se jen to co se pouzije.

klokan

Re:Conditional conformance v OOP
« Odpověď #8 kdy: 19. 02. 2018, 03:28:52 »
Je bezpečné stejně jako Java nebo C++ v tom smyslu, že co projde překladem, nespadne.

HAHAHAHA. A ten o policajtech, co musí chodit ve třech, znáte?

Programy v Javě padají naprosto běžně. V C++ se ve vyjímečných případech může stát, že to, co projde překladem, nespadne. Go má drtivou většinu stejných zdrojů pádů, jako C++: neinicializované nebo náhodné ukazatele, dereference NULL, race conditions, paměťové leaky (které garbage collector neodchytí), divoké přetypovávání atd. Snad jedině nekontrolovatelné duplikace a kontrola mezí polí jsou v Go přece jenom trochu líp řešené.

Statický duck typing à la Go je taky nebezpečný, protože když u nějakého parametru předpokládáte metodu tentononc(), úplně klidně se může stát, že se úplně jiná metoda stejného jména objeví třeba v knihovně, nebo ji jinde implementuje jiný člen týmu. Překladač to vezme a bude spokojený, že nároky na rozhraní objektu jsou splněné, ovšem při běhu to pak bude dělat psí kusy.

Což vůbec neznamená, že Go není dobrý jazyk. Je, mám ho docela rád, a na to, k čemu je primárně určený, je dokonce výborný, stejně jako Python nebo Smalltalk jsou skvělé jazyky ve svých vlastních oborech. Ale bezpečné Go prostě není, a staticky prokazatelně bezpečné už vůbec ne. Na bezpečnost je Rust nebo případně Ada, na snadné programování na vysoké úrovni je Python, a Go je výborný kompromis mezi snadnou použitelností jazyků, jako Python, a rychlostí staticky kompilovaných jazyků.

Labrat

Re:Conditional conformance v OOP
« Odpověď #9 kdy: 19. 02. 2018, 03:50:04 »
Je ale spousta věcí, včetně plné podpory monád, které tak doopravdy implementovat nejdou. Je to velká škoda a je zajímavé, že i Swift se rozhodl se takto omezit. Rád bych věděl, co návrhářům moderních jazyků na typech vyšších druhů tolik vadí?
U Swiftu je k tomu diskuse na fóru vývojářů. Tvrdí, že většina lidí by to nepoužívala, protože to nechápe.

Labrat

Re:Conditional conformance v OOP
« Odpověď #10 kdy: 19. 02. 2018, 04:01:18 »
Je bezpečné stejně jako Java nebo C++ v tom smyslu, že co projde překladem, nespadne.

HAHAHAHA. A ten o policajtech, co musí chodit ve třech, znáte?

Programy v Javě padají naprosto běžně. V C++ se ve vyjímečných případech může stát, že to, co projde překladem, nespadne. Go má drtivou většinu stejných zdrojů pádů, jako C++: neinicializované nebo náhodné ukazatele, dereference NULL, race conditions, paměťové leaky (které garbage collector neodchytí), divoké přetypovávání atd. Snad jedině nekontrolovatelné duplikace a kontrola mezí polí jsou v Go přece jenom trochu líp řešené.

Statický duck typing à la Go je taky nebezpečný, protože když u nějakého parametru předpokládáte metodu tentononc(), úplně klidně se může stát, že se úplně jiná metoda stejného jména objeví třeba v knihovně, nebo ji jinde implementuje jiný člen týmu. Překladač to vezme a bude spokojený, že nároky na rozhraní objektu jsou splněné, ovšem při běhu to pak bude dělat psí kusy.

Což vůbec neznamená, že Go není dobrý jazyk. Je, mám ho docela rád, a na to, k čemu je primárně určený, je dokonce výborný, stejně jako Python nebo Smalltalk jsou skvělé jazyky ve svých vlastních oborech. Ale bezpečné Go prostě není, a staticky prokazatelně bezpečné už vůbec ne. Na bezpečnost je Rust nebo případně Ada, na snadné programování na vysoké úrovni je Python, a Go je výborný kompromis mezi snadnou použitelností jazyků, jako Python, a rychlostí staticky kompilovaných jazyků.
Leaky? GC v současném Go odchytne vše (na rozdíl od první verze), co je na GC haldě (legální je ovšem i přetahování odkazu na pole z C).

K bezpečnosti, Go je bezpečné do té míry, že pokud kontroluju chybové hodnoty, program nechcípne. To znamená testovat návratovou hodnotu ok u map a přetypování, err všude, kde se vrací jako druhá hodnota apod.

klokan

Re:Conditional conformance v OOP
« Odpověď #11 kdy: 19. 02. 2018, 04:59:16 »
U Swiftu je k tomu diskuse na fóru vývojářů. Tvrdí, že většina lidí by to nepoužívala, protože to nechápe.

Totéž tvrdí vývojáři Rustu. Možná, že konkrétně v případě Swiftu na tom něco je, přece jenom je to jazyk určený především na vývoj appek pro iPhone, takže HKT a monádám v této cílové skupině asi hodně lidí opravdu moc nerozumí (ačkoli nevím, jestli to je dobrý důvod pro to, aby to nebylo).

Labrat

Re:Conditional conformance v OOP
« Odpověď #12 kdy: 19. 02. 2018, 05:10:21 »
U Swiftu je k tomu diskuse na fóru vývojářů. Tvrdí, že většina lidí by to nepoužívala, protože to nechápe.

Totéž tvrdí vývojáři Rustu. Možná, že konkrétně v případě Swiftu na tom něco je, přece jenom je to jazyk určený především na vývoj appek pro iPhone, takže HKT a monádám v této cílové skupině asi hodně lidí opravdu moc nerozumí (ačkoli nevím, jestli to je dobrý důvod pro to, aby to nebylo).
Jako důvod to je debilní, oficiálně to je ale na TO DO seznamu, jen s nízkou prioritou. Mě Swift moc nebere, protože je dost Apple-centric a já píšu hlavně pro Linux, ale HKT používám v C++ (ať žije statický polymorfismus) a rozhodně bych rád, aby se rozšířily.

klokan

Re:Conditional conformance v OOP
« Odpověď #13 kdy: 19. 02. 2018, 05:29:21 »
Leaky? GC v současném Go odchytne vše (na rozdíl od první verze), co je na GC haldě (legální je ovšem i přetahování odkazu na pole z C).

Tak jo, nesledoval jsem to zas tak bedlivě, takže jestli to opravili, tím líp. Řeší to i známý bug, kdy GC neuvolňoval kanál, na který čekala gorutina, po té, co skončil producer?

K bezpečnosti, Go je bezpečné do té míry, že pokud kontroluju chybové hodnoty, program nechcípne. To znamená testovat návratovou hodnotu ok u map a přetypování, err všude, kde se vrací jako druhá hodnota apod.

To není pravda. Příklad:

Kód: [Vybrat]
func main() {
        c := make(chan string)
        go func() {
                msg := <- c
                fmt.Println(msg)
                c <- "hello"
        }()

        msg := <- c
        fmt.Println(msg)
        c <- "world"
}

Žádné chybové hodnoty nikde nejsou, přeloží se to v pohodě bez warningů, ale zkuste si to pustit. Bum.

NB: v Rustu se stejný program ani nepřeloží, protože vede k typové chybě, kterou kompiler detektuje.

klokan

Re:Conditional conformance v OOP
« Odpověď #14 kdy: 19. 02. 2018, 05:34:19 »
Jako důvod to je debilní, oficiálně to je ale na TO DO seznamu, jen s nízkou prioritou. Mě Swift moc nebere, protože je dost Apple-centric a já píšu hlavně pro Linux, ale HKT používám v C++ (ať žije statický polymorfismus) a rozhodně bych rád, aby se rozšířily.

Jakže děláte HKT v C++? To by mě docela zajímalo.