A když se to spojí, tak máme ten hypotetický jazyk, který by dokázal nahradit testy v případech užití, které byly uváděny.
Uváděn byl příklad dvou funkcí pro sumaci. Nějak ho stále přehlížíte.
Obávám se, že to není nijak podstatné.
Byly časy, kdy API funkce (říkejme tomu spíše signatura) vypadala nějak takto:
function substr(String str, Int start, Int len) : String
A v praxi jsme pak museli ošetřit testem, co se stane, když zavoláme substr("abc", 6, -2). Někde uvnitř té funkce bylo definováno, že to má vyhodit výjimku, prázdný řetězec, nebo něco takového. Podstatné ale je, že signatura funkce o této nesmyslnosti nic nevěděla.
Dnes už máme typy na takové úrovni, že dokážeme zohlednit, že substr("abc", 6, -2) nepůjde vůbec přeložit. A myslím, že nikoho nijak zvlášť nezajímá, že kdysi dávno se tvrdilo, že ošetření těchto nesmyslných vstupů je otázka implementace, a nikoliv API/Signatury.
Takže pokud trváš na tom, že API/Signatura a implemnetace/chování jsou dva oddělené světy, tak já ti tvůj názor přeji, ale v takovém případě nám nejde o stejnou věc.
Ale já nepíšu o signatuře, píšu o API. A součástí API té funkce substr je, že někde v dokumentaci, např. v manuálové stránce, je napsáno, co ta funkce má dělat, a v lepším případě i jaké jsou možné parametry a co to bude dělat, pokud budou parametry mimo rozsah. V horším případě tam zejména ty chybové stavy moc dobře popsané nebudou , a pak nastává ten případ, o kterém jsem také psal, že se mohou lišit názory na to, jaké je vlastně přesné API té funkce.
To ze se nekdo rozhodl, ze nebude formalizovat veskere pozadavky na funkci, a ze neco jen popise v dokumentaci, neni proto, ze by to neslo, ale proto ze se mu nechtelo.
BoneFluteovi se chce.
Že API a implementace jsou dva oddělené světy jsem uváděl na tom příkladu se sumací, který raději ignorujete. Mimochodem, je to uváděné jako základní vlastnost API, že odstíní uživatele od konkrétní implementace, takže implementace se může měnit, aniž by se o tom uživatel dozvěděl. Znáte třeba POSIX?
Kdyz se zamyslim nad tim prikladem se sumaci tak mi prijde, ze to neni idealni. Tim rikam, ze bude ta funkce pracovat jen s nejakou linearni kolekci a dost se tim omezuji.
Kdyby byl na vstupu misto toho iterator tak dosahnu vetsi znovupouzitelnosti. A jen tak mimochoddem ziskam to, ze smer iterace bude dany tim iteratorem a ne zakodovany v implementaci te sumy.
Jak nemůže? Proč by nemohl? Ať je platforma jakákoliv, tak čas bude všude stejný ne? Této argumentaci nerozumím.
Nechcete doufám tvrdit, že stejný kód poběží stejně rychle na 386 a na dnešních výkonných procesorech? Že poběží stejně rychle na Raspberry Pi, na chytrém telefonu i na pracovní stanici?
By me zajimalo jestli v Turbo pascalu sli vubec napsat hodiny, nebo treba stopky...
http://computer-programming-forum.com/29-pascal/c1fd619ca94be881.htmJen si to představ. Vezmeš nějakou hru a dáš ji přeložit pod 486kou, a ono ti to odmítne, protože nejde zaručit potřebnou rychlost. Horní mez je sranda, to stačí jen oříznout.
Tak samozřejmě se můžeme bavit o tom, jak to zjistit, jak moc to jde zaručit, ale je třeba myslet na kontext tohoto vlákna. Porovnáváme to s testy. Pokud to nezvládneš ani testy, tak není nutné řešit jak to udělat typy.
Jak přeložit pod 486? Vy jí máte k dispozici? A máte k dispozici i budoucí procesory? Navíc rychlost té funkce by přece musela být zakódovaná v tom typu.
Testy se tohle řeší snadno. Napíše se test, který bude měřit dobu běhu té funkce a zkontroluje, že je v daném rozmezí. Že ten test odhalí chybu, až když ho spustím na příslušném zařízení? Ano, to je vlastností testů, že nejsou prevencí chyb, ale umožňují chyby rychle nalézat po té, co k chybě došlo.
Takze az napisu tu hru a budu ji prodavat skolakum tak je slusne poprosim, aby mi na svem stroji napred pustili testy z diskety 2?
Že testy nepokrývají všechny případy? Ano, i to je vlastností testů, a to umožňuje, aby se testy vůbec v reálném světě používaly. Protože programování je stále založené na tom, že se vybírají ty podstatné věci, které se vyjádří v programu, a všechny ostatní nepodstatné se ignorují. Takže se třeba v definici API ignorují záporné hodnoty indexu funkce substr, protože přece nikdo soudný nebude předávat záporný index.
Co kdyz se si zvykl na negativni indexovani v pythonu? Nejsem soudny?
Zobrazit příspěvky
