To by mě zajímalo, proč bys zrovna z těchto důvodů tohle psal v dynamickém jazyku....
Že je to dynamický jazyk přece bylo vaše zadání. Kdybych chtěl kontrolovat, že jsou tam správné typy, budu to kontrolovat, a jednotkové testy budou dělat to, že budou mít vstupy s různě pokaženými typy a budou testovat, že funkce pro načtení dat skončí správnou chybou. Pak vůbec nezáleží, jaký je typový systém, protože třeba v souboru na disku můžu mít ta data jakákoli, a při načtení musím kontrolovat, že načítaná data jsou validní.
já fakt nesouhlasím s:
To záleží na kontextu. Pokud se bude pohybovat v kódu, kde bude většina typů non-null, a výjimečně narazí na nullable typ, ošetří to. Pokud bude z venku neustále dostávat nullable typy a použité typy a typový systém ho budou nutit neustále to přetypovávat, bude to dělat automaticky bez přemýšlení.
a řekl bych že výše uvedený příklad ukazuje, že to prostě není pravda.
Podle mne se tady nedá na jednom příkladu ukázat, že to není pravda. Vždyť tvrdím, že když donutíte člověka něco dělat opakovaně skoro pokaždé v nějaké situaci, bude to v podobných situacích dělat bez přemýšlení. To je úplně nezávislé na programování, lidé takhle automaticky odklepávají potvrzovací dotazy, pokud se jich aplikace pořád ptá na nějaké nesmysly (třeba jestli má smazat soubor), vjíždí na železniční přejezd, když nebliká červená – a úplně stejně budou do programu automaticky vkládat konstrukci na přetypování na non-null typ, pokud to tak budou používat ve většině případů. Jako příklad budiž třeba implementace escapování jako obrany před SQL injection nebo XSS – pokud se to někde nechalo tak, že si to musel každý ve svém kódu ošetřit sám, bylo vzápětí escapování všude, takže se jeden řetězec escapoval několikrát (což samozřejmě nefungovalo). Dotyčný autor nad tím vůbec nepřemýšlel, jestli je v kontextu kdy musí nebo nesmí escapovat, prostě tu konstrukci bez rozmýšlení mydlil všude.
A ze stejných důvodů nesouhlasím s tímto:
I tenhle typ chyby se bude objevovat u sebelepšího typového systému, protože když programátora nenapadne, že to je zajímavý případ a měl by na to udělat test, nenapadne ho ani ošetřit to v typovém systému.
Protože například u té nullpointerexception je prostě používání "Maybe" typu na úplně jiné úrovni než dávat někam asserty a psát k tomu unit testy.
Rozlišování nullable/non-null typů je myslím extrémní případ, kdy je použití extrémně snadné a pro programátora srozumitelné. Souhlasím s tím, že tohle je případ, kdy je řešení pomocí typů nejlepší řešení. Ale jen o málo složitější věci by typově správně byly nesmírně komplikované, a nebo tam zase musíte povolit potenciální chyby, a programátor to neuhlídá.
Zkuste vzít jako příklad jednoduché porovnání dvou čísel splňující kontrakt „pokud je první číslo větší, vrací zápornou hodnotu, pokud jsou stejná, vrací nulu, pokud je druhé číslo větší, vrací kladnou hodnotu“. Nejjednodušší řešení je čísla odečíst – jenže se může stát, že dojde k přetečení. Může se to ošetřit typově – při sčítání nebo odčítání dvou čísel bude mít návratový typ dvojnásobný rozsah. Jenže se to začne nabalovat, a za chvíli skončíte s datovým typem, který se ani nevejde do paměti. A nebo to budete ošetřovat a pokud by došlo k přetečení typu, vyhodí se výjimka. Jenže pak zase potřebujete jednotkové testy, protože typový systém by vám možná zajistil, že program neudělá skrytě nic špatně, ale raději vyhodí výjimku, ale testy pak potřebujete na to, abyste zkontroloval, že aspoň někdy to skončí jinak, než výjimkou.
Zobrazit příspěvky
