Co si myslíte o OOP?

[Kit]

Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.

Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???

Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.

Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?

[Reklama]

[BaldSlattery]

Statická typová kontrola zabrání určité třídě chyb v programu, protože nepovolí použití neočekávaných typů. Pokud mají být testy plnohodnotnou náhradou, měly by všechny tyto chyby odchytit taky (nepřu se o to, že testy mohou zachytit i spoustu jiných chyb, na které naopak nestačí typová kontrola). Je mi celkem jedno, jak budou testy vypadat, ale aby odpověď nebyla triviální, neměly by zahrnovat nic, co je jen převlečená statická typová kontrola přesunutá z kompilátoru do testovacího prostředí (tedy žádná statická analýza zdrojáků s použitím typových anotací).

Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.

Naproti tomu se mi typové anotace nelíbí, to už raději v hlavičce metody ten typ použiji. Problém však nastane, pokud jsou přípustné paranetry různých typů. U statického typování se to řeší přetěžováním, což může pro různé kombinace typů parametrů znamenat značné množství metod. U dynamického se to může vyřešit v jedné metodě.

To není pravda, takové metody používají buď generika, nebo rozhraní. V C++ můžu říct, že parametr je “auto”, a překladač si s tím poradí. Chyby se řeší koncepčně (Concepts TS).

[BaldSlattery]

Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.

Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???

Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.

Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?

Tak nemá smysl cpát je do batohu, to by si stěžoval i Smalltalk.

[Kit]

Typove anotace jsou dobra pomucka, svuj smysl maji treba u verejneho rozhrani. Vyhodou u nich je, ze nejsou povinne, takze je programator je nemusi otrocky pouzivat tam, kde nemaji smysl nebo dokonce program zbytecne komplikuji.

Záleží na jazyku. V Pythonu jsou typové anotace v pořádku, ale v PHP uváděné anotace do dokumentace jsou hnusné. Když se v PHP metoda otypuje, tak to vypadá podobně jako typová anotace v Pythonu.

[Kit]

Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.

Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???

Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.

Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?

Tak nemá smysl cpát je do batohu, to by si stěžoval i Smalltalk.

Mám je na seznamu věcí, které chci do toho batohu dát. Předměty, které to rozhraní nesplní, však do toho batohu dávat nebudu. Pokud ten seznam obsahuje takové nesmysly, tak to ještě nemusí znamenat, že ten seznam zahodím a prohlásím, že nikam nejedu.

[Reklama]

[BaldSlattery]

Nemá smysl řešit, že použijete např. typový seznam, když to potřebujete. Problémem u statických jazyků je použití seznamu v případě, kdy v něm potřebujete různé prvky.

Příklad: Mám batoh s danou nosností a objemem a (netypový) seznam blíže neurčených předmětů (= nezajímá mě, co to je), jejichž jediným společným prvkem (a to ještě ne nutně) je, že odpovídají na zprávu "hmotnost" a "velikost", a chci zjistit, zda se mi do toho batohu vlezou. Jak se to řeší typovaným seznamem???

Rozhraním, ne? V ObjC se to jmenuje protokol, řekne se, jakou metodu má implementovat, a zbytek už je triviální.

Jenže co když některé položky seznamu toto rozhraní nesplňují a tuto metodu implementovánu nemají?

Tak nemá smysl cpát je do batohu, to by si stěžoval i Smalltalk.

Mám je na seznamu věcí, které chci do toho batohu dát. Předměty, které to rozhraní nesplní, však do toho batohu dávat nebudu. Pokud ten seznam obsahuje takové nesmysly, tak to ještě nemusí znamenat, že ten seznam zahodím a prohlásím, že nikam nejedu.

Tak v tom případě nemáš vůbec žádný problém, napiš si to třeba v Go, je to poučné.

[Kit]

Mám je na seznamu věcí, které chci do toho batohu dát. Předměty, které to rozhraní nesplní, však do toho batohu dávat nebudu. Pokud ten seznam obsahuje takové nesmysly, tak to ještě nemusí znamenat, že ten seznam zahodím a prohlásím, že nikam nejedu.

Tak v tom případě nemáš vůbec žádný problém, napiš si to třeba v Go, je to poučné.

Totéž si mohu napsat i v PHP, Pythonu nebo některém z mnoha dalších dynamicky typovaných jazyků.

[M]

@ není anotace, ale dekorátor. Takovou classmethod si můžete zjednodušeně představit...

Je mi buřt, jak se to jmenuje (dekorátor je pro mě návrhový vzor), vnitřní implementace je nepodstatná. Představoval bych si, že vedle klíčového slova def tu bude např. classdef, aby bylo jasné, co je definováno na třídní a co na instanční straně. Tyto anotace/dekorátory na mě dělají dojem dobastlovaného jazyku.

Ty "neobjektové" funkce si představte jako implementaci určitého protokolu. Díky duck typingu nemusí mít objekt miliardy metod pro všechny možné situace. Proto také můžou existovat věci jako len(), iter(), next(), ... které ho využívají. Pokud vím, že něco je kolekce, len() na to bude fungovat a určitým postupem zjistí, kolik je v ní prvků. Taky můžu udělat např. max(map(len, iterable)). max(map(lambda i: i.len(), iterable)) by bylo krkolomnější. Rubysta by namítl, že iterable.collect(&:len) je lepší, ale každý jazyk má své vlastnosti

Nechápu. Proč budu "určitým postupem" zjišťovat, kolik je v kolekci prvků, když se jí můžu rovnou zeptat? Oč jsou uvedené funkce jednodušší, koncepčnější a přehlednější než seznam.len(), seznam.forEach(), seznam.max(), ... Tohle se mi jeví jako zbytečný bastl za účelem lezení do zadku uživatelům zvyklým na imperativní jazyky.

Pepa vyrobí .size(), Franta vyrobí .length(), Honza vyrobí .len() ... a pak se v tom vyznej (to už se mi stalo).

Generické věci využívající generické protokoly nemusí bordelit třídní namespace a zbytečně komplikovat dědičnost. Například len() se podívá, jestli si třída implementuje __len__ a pokud ne, tak si ji projde a spočítá počet prvků, takže funguje s čímkoliv, co je iterable. Ditto ostatní takové věci. Ale Control-Space Enter, já vím.

Navíc python do jisté míry podporuje funkcionální styl programování, kde se přesně takové věci dělají. A když už mám jazyk, co takové programování podporuje, tak proč bych to nevyužil? Šetří to psaní, lépe se píšou výrazy ve funkcionálním stylu.

A ano, třídy a objekty jsou v pythonu víceméně pouze "glorifikované dicty", které se dají měnit jak se zamane. Je ale na odpovědnosti programátora, aby psal slušně a ne jak prase. Když si někde vytvořím _my_private, tak by v code review mělo být nad slunce jasné, že když někdo napíše neco._my_private, že je něco asi špatně.

Když se člověk začte do dokumentace, tak zjistí, že vnitřnosti jsou poměrně jednoduché a jsou okolo mechanismy, které se dají ovlivnit aby si člověk ušetřil psaní, zkontroloval data, která se předávají, vytvořil něco na způsob DSL... Takový přístup umožňuje větší kontrolu nad tím, co se děje a nabízí více možností, jak splnit úkol. A třeba to i pěkně napsat.

[BoneFlute]

Pak samozřejmě můžeš dojít k závěru, že nevíš, a že tam chceš dát cokoliv. Tak dáš typ *, a budeš tam moct uložit opravdu cokoliv.

Vizte můj příspěvek dříve: Není problémem vytvořit seznam s prvky typu objekt a najebat do něj cokoliv, problémem je potom nad tímto seznamem spustit sumu na vlastnost "cena" nebo "objem". Jak se to udělá v statickém jazyku?

Není to problém. Prostě nad tím pustím tu funkci sum() která vynucuje vlastnost "cena" či "objem". A ono se to transitivně propíše i do toho seznamu. Takže někdy v tom okamžiku mi kompilátor začne řvát, že tam má něco nedomyšleného, ať to laskavě domyslím.

[BaldSlattery]

Mám je na seznamu věcí, které chci do toho batohu dát. Předměty, které to rozhraní nesplní, však do toho batohu dávat nebudu. Pokud ten seznam obsahuje takové nesmysly, tak to ještě nemusí znamenat, že ten seznam zahodím a prohlásím, že nikam nejedu.

Tak v tom případě nemáš vůbec žádný problém, napiš si to třeba v Go, je to poučné.

Totéž si mohu napsat i v PHP, Pythonu nebo některém z mnoha dalších dynamicky typovaných jazyků.

Bez typové kontroly. V C++, Go, ObjC nebo Swiftu to máš stejně flexibilní a s kontrolou.

[operator]

V tom řádku s Just je právě schválně chyba. Kde statický jazyk si "všimne" při překladu, že x není string. To považuju za dost "světodějný".

Ajo, promiň, toho jsem si nevšiml. Ale co tím demonstruješ? Jenom to, že statické jazyky umí některé chyby odhalit už v době překladu. To ale přece všichni víme, ne?!

A proč to demonstrovat tak krkolomně? Stačilo úplně:

Kód: [Vybrat]

def some_func_anywhere():
  return 1 + "x"
- Python ti tohle ochotně pustí do produkce i když by to krásně mohl odhalit. No, je to tak, dělá míň práce, než by mohl

To do produkce nepusti Python, ale programator. Spravne to ma vypadat takto:

Kód: [Vybrat]

~ $ cat tt.py
def some_func_anywhere():
    """
    Function raise TypeError exception.
    >>> some_func_anywhere()
    Traceback (most recent call last):
        ...
    TypeError: unsupported operand type(s) for +: 'int' and 'str'
    """
    return 1 + "x"

if  __name__ == '__main__':
    import doctest
    print(doctest.testmod())
~ $ python tt.py
TestResults(failed=0, attempted=1)

A pak je v poradku, ze se to pusti do produkce, protoze funkce dela to co ma delat.

[MartinBeran]

Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.

Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat. To z mnoha důvodů většinou nejde. Proto se snažíme dokázat (rozhodnout na základě statické analýzy zdrojových textů, pro všechny možné vstupy a bez nutnosti program spouštět) aspoň něco. Statická typová analýza je jedním z nástrojů, jak dokázat aspoň některé vlastnosti programu. Jestliže nějaké tvrzení o programu dokážeme (v matematickém slova smyslu), tak si můžeme být jistí, že platí.

Na druhou stranu testy většinou žádné obecné tvrzení o programu nedokazují, protože je není možné napsat tak, aby pokryly úplně celý stavový prostor programu. Takže se spoléháme na to, že otestujeme některé speciální situace, v lepším případě zvolené "chytře", např. na základě znalosti kódu, v horším případě vybrané náhodně, v nejhorším případě vybrané systematicky špatně. Když testy neohlásí chybu, tak věříme, že je program dobře. Ale ve skutečnosti jsme jen ověřili, že nenastane chyba pro určitou (většinou malou) podmnožinu vstupů. A to ještě za předpokladu, že nějaká chyba v testu nezamaskuje přítomnost chyby v kódu.

 Když mám k dispozici dva kontrolní mechanismy, které jsou do značné míry komplementární, tak se mi nezdá vhodné jeden z nich zahodit (a ještě ten s principiálně silnější vypovídací schopností) a tvářit se, že jsem zachoval stejnou úroveň kontroly.

[Lojza]

mne by treba zajimalo proc se dynamicke jazyky zatim neprosadily u life saving real time mission criticial systems, ktere se nejspis vyvijeji jen v silne typovych jazycich, napr. v Ade resp. v jazycich ktere jsou jeji podmnozinou


https://en.wikipedia.org/wiki/Ada_(programming_language)


https://en.wikipedia.org/wiki/SPARK_(programming_language)


https://en.wikipedia.org/wiki/Ravenscar_profile


nebo je to jinak ?

[operator]

Při statickém typování se neobejdeš bez testů, používáš tedy dva kontrolní mechanismy. Cílem tvůrců Smalltalku bylo tyto dva mechanismy sloučit do jednoho, tedy do testů. U dynamicky typovaných jazyků jsou tedy v testech i kontroly typů.

Jenže ideální by bylo se obejít zcela bez testů a správnost programu dokázat.

To je samozřejmě hloupost a realita je přesně opačná, bez testů se neobejdeme, bez _statických_ typů ano. Statické typy mají jediné opodstatnění, výkon. Ve všem ostatním jsou nahraditelné.

[operator]

mne by treba zajimalo proc se dynamicke jazyky zatim neprosadily u life saving real time mission criticial systems, ktere se nejspis vyvijeji jen v silne typovych jazycich, napr. v Ade resp. v jazycich ktere jsou jeji podmnozinou


https://en.wikipedia.org/wiki/Ada_(programming_language)


https://en.wikipedia.org/wiki/SPARK_(programming_language)


https://en.wikipedia.org/wiki/Ravenscar_profile


nebo je to jinak ?

Doporucuji neplest si silne a staticke typovani.