Typový system versus unittesty

[Bacsa]

Například jazyk Elm by toto mohl dát. Jakmile někdo vezme funkci, a ohne si ji, tak se změní major verze té funkce a už nepůjde napasovat, a celé to nepůjde zkompilovat. Což je IMHO právě ta ochrana (ochrana rozhodně užitečná), o které mluvíš.

Při popisu toho, proč se používají testy, jste popsal jenom jednu možnou změnu. Druhá možná změna je, že někdo vezme funkci, zachová její API na kterém závisí ostatní a které testují testy, ale upraví její implementaci (např. funkci optimalizuje). Užitečnost ochrany testy spočívá i v tom, že testy dále úspěšně procházejí, přestože se implementace změnila. Testy nejsou určené k tomu, aby nacházely změny, ale aby nacházely takové změny, které něco rozbijí.

Ale ne. On ma BoneFlute zase pravdu. Uz mi to doslo.
Kdyz bude funkce ochranena typem tam nepujde ohnout aniz by se zmenil ten typ a tudiz kompilator stejne zarve protoze tam kde ji volam ja bude typ nekompatibilni.

Něco podobného je popsáno v Seven more languages in seven weeks.

[Reklama]

[BoneFlute]

Kdyz bude funkce ochranena typem tam nepujde ohnout aniz by se zmenil ten typ a tudiz kompilator stejne zarve protoze tam kde ji volam ja bude typ nekompatibilni.

Ano, přesně tak.

Mimochodem docela inspirativní, a dokonce z produkce je jazyk Rust a jeho borrows. Což je zase něco jiného než s čím se obvykle setkáváme. Je zajímavé, kolik chyb je schopen při kompilaci najít.

[Filip Jirsák]

Kdyz bude funkce ochranena typem tam nepujde ohnout aniz by se zmenil ten typ a tudiz kompilator stejne zarve protoze tam kde ji volam ja bude typ nekompatibilni.

Nechápu, proč to píšete jako reakci na můj komentář, když jste jen znovu napsal to, na co jsem já reagoval. Já jsem psal o opačném případu, kdy používané API funkce zůstane stejné, ale implementace se změní (což nemusí nutně znamenat, že nová implementace bude ekvivalentní té původní – nesmí se změnit API, ale vlastnosti, na kterých nic nezávisí, se změnit mohou).

[optimizer]

zatím se tu neobjevil jediný kus fungujícího kódu.

[listoper]

Kdyz bude funkce ochranena typem tam nepujde ohnout aniz by se zmenil ten typ a tudiz kompilator stejne zarve protoze tam kde ji volam ja bude typ nekompatibilni.

Nechápu, proč to píšete jako reakci na můj komentář, když jste jen znovu napsal to, na co jsem já reagoval. Já jsem psal o opačném případu, kdy používané API funkce zůstane stejné, ale implementace se změní (což nemusí nutně znamenat, že nová implementace bude ekvivalentní té původní – nesmí se změnit API, ale vlastnosti, na kterých nic nezávisí, se změnit mohou).

Mozna proto, ze ten typovy system muze zajistit, ze (breaking) zmena  implementace nepujde udelat beze zmeny API?

[Reklama]

[Filip Jirsák]

Mozna proto, ze ten typovy system muze zajistit, ze (breaking) zmena  implementace nepujde udelat beze zmeny API?

Zkusím to ještě potřetí: aby to mohlo nahradit jednotkové testy, musel by ten typový systém zároveň zajistit, že změna implementace, která nezmění používané API, nic nerozbije – tedy že např. nedojde k nekompatibilní změně typů. Pro jistotu ještě explicitně uvedu, že „nemění používané API“ neznamená, že se nijak nezmění chování té funkce navenek. Např. pokud se ta funkce používala jen pro vstupní hodnoty 1–10, když se změní výsledek, který vrací pro 11, není to změna používaného API.

[Honza]

Je to jenom jiný úhel pohledu pořád na totéž:

Formální správnost programu vs. zamýšlená funkčnost.

...zatímco nepřátelé jednotkových testů přitom marně čekají na akademický důkaz, že obojí typový systém NEzvládne, aby se mohli při tom čekání chlácholit tím, že do té doby mají pravdu...

Takhle tu budete v tom případě asi debatovat ještě hodně dlouho...

[listoper]

Pro jistotu ještě explicitně uvedu, že „nemění používané API“ neznamená, že se nijak nezmění chování té funkce navenek. Např. pokud se ta funkce používala jen pro vstupní hodnoty 1–10, když se změní výsledek, který vrací pro 11, není to změna používaného API.

Pokud je vstupni typ funkce integer 1 - 10 tak aby zacala vracet i pro 11 budu muset zmenit typ vstupu. Takze API.

[Filip Jirsák]

Pokud je vstupni typ funkce integer 1 - 10

Není. Opravdu je nutné to explicitně psát, není to zřejmé z předchozího komentáře?

[BoneFlute]

zatím se tu neobjevil jediný kus fungujícího kódu.

Bez ohledu na to, zda máte pravdu, toto nebylo požadavkem.

[BoneFlute]

Je to jenom jiný úhel pohledu pořád na totéž:

Formální správnost programu vs. zamýšlená funkčnost.

...zatímco nepřátelé jednotkových testů přitom marně čekají na akademický důkaz, že obojí typový systém NEzvládne, aby se mohli při tom čekání chlácholit tím, že do té doby mají pravdu...

Takhle tu budete v tom případě asi debatovat ještě hodně dlouho...

Já si pamatuju na kdysi, kdysi nějaký vlákno fóra, kde se rozebíralo statické typování, haskell, python. Bylo to dlouhý, a hodně inspirativní. Třeba jen od tohoto vlákna očekáváš něco, co není jeho cílem. Někteří z nás tu třeba nechtějí najít univerzální rozhodnutí, nebo si nepotřebují nic dokazovat. Jen se pokoušíme zjistit, co kdo k tomu ví zajímavého. Můžeš k tomu pomoct. (Ale taky nemusíš :-) )

[BoneFlute]

Pro jistotu ještě explicitně uvedu, že „nemění používané API“ neznamená, že se nijak nezmění chování té funkce navenek. Např. pokud se ta funkce používala jen pro vstupní hodnoty 1–10, když se změní výsledek, který vrací pro 11, není to změna používaného API.

Pokud je vstupni typ funkce integer 1 - 10 tak aby zacala vracet i pro 11 budu muset zmenit typ vstupu. Takze API.

Jen doplním, že ten Elm si zjistí, zda došlo k nekompatabilní změně algoritmu, a tuto změnu propíše do API jako tu major verzi. Takže ten semver je součástí toho typu. Vzhledem k tomu, že Elm je téměř pure, tak to nepřekvapí. Bylo by zajímavé zjistit, kde má hranice (já jsem se tomu žel nevěnoval tolik, kolik bych chtěl - zatím).

[Filip Jirsák]

Jen doplním, že ten Elm si zjistí, zda došlo k nekompatabilní změně algoritmu, a tuto změnu propíše do API jako tu major verzi.

Jak už jsem několikrát psal, naposledy v komentáři, na který reagujete, ne každá nekompatibilní změna algoritmu je nekompatibilní i z hlediska API.

[listoper]

Jen doplním, že ten Elm si zjistí, zda došlo k nekompatabilní změně algoritmu, a tuto změnu propíše do API jako tu major verzi.

Jak už jsem několikrát psal, naposledy v komentáři, na který reagujete, ne každá nekompatibilní změna algoritmu je nekompatibilní i z hlediska API.

A to prave nemusi byt pravda.

[Filip Jirsák]

Jak už jsem několikrát psal, naposledy v komentáři, na který reagujete, ne každá nekompatibilní změna algoritmu je nekompatibilní i z hlediska API.

A to prave nemusi byt pravda.

Asi jste můj komentář špatně přečetl. Psal jsem, že existují takové nekompatibilní změny implementace, které nemění API. Tvrzení o existenci se vyvrací tvrzením, že neexistuje žádný takový případ. Tedy žádné „nemusí“, ale „nemůže existovat“.

Nezapomínejte na to, že definice API nemusí být jenom to, co je v kódu, ale mohou to být další podmínky nebo omezení popsané třeba v dokumentaci. A tu si žádný kompilátor nepřečte.