Co si myslíte o OOP?

[SB]

Testy není nutné psát dřív než kód. U některých je to dost nevhodné. Kdybych bral poslední dvě věty doslova, tak nevím, jak poznám, že je program připraven pro produkční nasazení.

No hlavně se vám to ani nepovede, protože ve statickém jazyku bez existence testovaného ani nepřeložíte test.

[Reklama]

[SB]

Staticke typy mohou pomoci pri overovani spravnosti kodu, ale jsou zbytne, nezbytne jsou testy. Staticke typy v tomto smeru hraji druhe housle.

Taky si to myslím. Typový systém nahradit testy jde. Testy typovým systémem taky, ale zatím jen teoreticky, prakticky to ještě nikdo nepředvedl. Otázkou tedy (stále) zůstává, zda mi to sraní s typy víc přinese než vezme. To si musí každý soudruh pořešit sám.

[SB]

Znamená to, že mám-li různé seznamy různých prvků, nad kterými potřebuju spouštět pokaždé jiné metody, musejí mít ony prvky rozhraní vždy s danou kombinací spouštěných metod, nebo rovnou pro každou metodu jedno rozhraní?

Jasně, že ne. Dělá se to jako protokoly třeba v ObjC. Když už někdo potřebuje takto heterogenní seznam, musí pak použít ve Smalltalk-like jazycích conformsTo: a jinde třeba typové aserce, implementace bývá zcela stejná.

Explicitně definovanými protokoly??? To je ale to samé co rozhraní.
Co to je "Smalltalk-like jazycích" V čistě obj. jazycích není žádná podmínka, abych mohl objektu poslat zprávu, o tom se tu bavíme!

[BaldSlattery]

Znamená to, že mám-li různé seznamy různých prvků, nad kterými potřebuju spouštět pokaždé jiné metody, musejí mít ony prvky rozhraní vždy s danou kombinací spouštěných metod, nebo rovnou pro každou metodu jedno rozhraní?

Jasně, že ne. Dělá se to jako protokoly třeba v ObjC. Když už někdo potřebuje takto heterogenní seznam, musí pak použít ve Smalltalk-like jazycích conformsTo: a jinde třeba typové aserce, implementace bývá zcela stejná.

Co to je "Smalltalk-like jazycích"

ObjC třeba. Nebo Smalltalk

[SB]

Kit to možná chtěl napsat opačně: Co když položky metodu implementovanou mají, ale není v rozhraní.

To je pak chyba v návrhu. Ve smalltalkoidním jazyce by nešlo použít conformsTo:, muselo by se sáhnout po respondsTo:, což je méně efektivní nejspíš ve všech jazycích, protože introspekce. Tohle je zřejmě důvod, proč je v Go konformance automatická. Nicméně pokud někdo udělá takovou botu třeba v Javě, tak musí sáhnout po reflexi jako ve Smalltalku, to není nic objevného.

A v kterém rozhraní má tedy být uvedena metoda např. pro hmotnost?
Smalltalk SERE na rozhraní či třídy, Smalltalk posílá zprávy, objekt vrací hodnotu, nebo chybu. To je celé!

[Reklama]

[BaldSlattery]

Kit to možná chtěl napsat opačně: Co když položky metodu implementovanou mají, ale není v rozhraní.

To je pak chyba v návrhu. Ve smalltalkoidním jazyce by nešlo použít conformsTo:, muselo by se sáhnout po respondsTo:, což je méně efektivní nejspíš ve všech jazycích, protože introspekce. Tohle je zřejmě důvod, proč je v Go konformance automatická. Nicméně pokud někdo udělá takovou botu třeba v Javě, tak musí sáhnout po reflexi jako ve Smalltalku, to není nic objevného.

A v kterém rozhraní má tedy být uvedena metoda např. pro hmotnost?
Smalltalk SERE na rozhraní či třídy, Smalltalk posílá zprávy, objekt vrací hodnotu, nebo chybu. To je celé!

Tak sem dej kód pro ten batoh, my ti tu pak vysvětlíme, kde děláš ve svém uvažování chybu.

[operator]

Staticke typy mohou pomoci pri overovani spravnosti kodu, ale jsou zbytne, nezbytne jsou testy. Staticke typy v tomto smeru hraji druhe housle.

Taky si to myslím. Typový systém nahradit testy jde. Testy typovým systémem taky, ale zatím jen teoreticky, prakticky to ještě nikdo nepředvedl. Otázkou tedy (stále) zůstává, zda mi to sraní s typy víc přinese než vezme. To si musí každý soudruh pořešit sám.

Testy typovym systemem nahradit nelze, protoze neexistuje zadne obecne spravne chovani platne pro vsechny pripady. Jeden a ten samy kod muze byt jednou spatne a po druhe dobre. Funkce, ktera ma na vstupu 1 a na vystupu 0 muze fungovat pro jeden pripad dobre a pro druhy spatne. Jestli funguje podle ocekavani se da zkontrolovat jedine testem, v kterem nase ocekavani bude zahrnuto.

[Kit]

Testy není nutné psát dřív než kód. U některých je to dost nevhodné. Kdybych bral poslední dvě věty doslova, tak nevím, jak poznám, že je program připraven pro produkční nasazení.

No hlavně se vám to ani nepovede, protože ve statickém jazyku bez existence testovaného ani nepřeložíte test.

To je právě účelem prvotního spuštění testu. Nesmí projít. Pokud by náhodou prošel, může to být chybou nebo také příznakem, že jsme hotovi.

[operator]

...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ě.

Bude to v code review stačit? Co interpret, ví o tom?

Ano, tohle by mohl interpret zachytit a poskytnout varovani. V praxi to zachyti lint.

Kód: [Vybrat]

~ $ cat xx.py
class Cls(object):
    def __init__(self):
        self.__var = 1

if  __name__ == '__main__':
    INS = Cls()
    print INS._Cls__var
~ $ pylint xx.py
Using config file /data/data/com.termux/files/home/.pylintrc
************* Module xx
R:  1, 0: Too few public methods (0/2) (too-few-public-methods)
E:  7,10: Instance of 'Cls' has no '_Cls__var' member (no-member)
W:  7,10: Access to a protected member _Cls__var of a client class (protected-access)

--------------------------------------------------------------------
Your code has been rated at -1.67/10 (previous run: -1.67/10, +0.00)

~ $ python2 xx.py
1


[Mirek Prýmek]

BTW tohle by měly mít všechny jazyky, je to praktické.

Souhlas, tohle je rozhodne jedna z tech svetlejsich stranek Gocka

[BoneFlute]

Testy typovym systemem nahradit nelze, protoze neexistuje zadne obecne spravne chovani platne pro vsechny pripady. Jeden a ten samy kod muze byt jednou spatne a po druhe dobre. Funkce, ktera ma na vstupu 1 a na vystupu 0 muze fungovat pro jeden pripad dobre a pro druhy spatne. Jestli funguje podle ocekavani se da zkontrolovat jedine testem, v kterem nase ocekavani bude zahrnuto.

To je samozřejmě pravda. Problém je v tom, že naopak je to ještě horší. Pár scénářů, které typy nezvládnou, zatímco většina scénářů, které pro změnu nezvládnou testy.

Takže druhé housle hrají testy.

[BoneFlute]

Taky si to myslím. Typový systém nahradit testy jde.

Nahraď mi prosím typy za testy u tohoto příkladu:

Kód: [Vybrat]

inc (x: Int) = x + 1
Každopádně problém místních je v tom, že si nečtou argumenty. Takže za mě končím.

[operator]

Testy typovym systemem nahradit nelze, protoze neexistuje zadne obecne spravne chovani platne pro vsechny pripady. Jeden a ten samy kod muze byt jednou spatne a po druhe dobre. Funkce, ktera ma na vstupu 1 a na vystupu 0 muze fungovat pro jeden pripad dobre a pro druhy spatne. Jestli funguje podle ocekavani se da zkontrolovat jedine testem, v kterem nase ocekavani bude zahrnuto.

To je samozřejmě pravda. Problém je v tom, že naopak je to ještě horší. Pár scénářů, které typy nezvládnou, zatímco většina scénářů, které pro změnu nezvládnou testy.

Takže druhé housle hrají testy.

A proto tu mame rozsirene jazyky bez statickych typu a vsechy programy psane v programech se statickymi typy je nutno dukladne testovat. To jsou mi pekne druhe housle. :-)

[Ondrej Nemecek]

IMHO by bylo užitečnější místo této diskuze vést polemiku ve formě série článků s různými autory. Autoři by museli lépe argumentovat a uvést konkrétní příklady, na které by se pak lépe reagovalo. Portál by měl přísun zajímavých článků a paradoxně by si možná všichni ušetřili čas promrhaný v diskuzi... :-D

[Mirek Prýmek]

Autoři by museli lépe argumentovat

Anebo by placali uplne stejne neplodne, neposlouchali se, vedli svuj monolog, akorat na desetkrat vetsi plose