Co si myslíte o OOP?

[Kit]

Aha, takže když uživatel místo int vloží text, tak necháš aplikaci slítnout? Hmm, to asi bude hodně stabilní.

Kite, Kite. Bavime se o chybach, ktere zpusobil programator, v tomto pripade dokonce o chybe, ktera by se dala odchytit pri prekladu, kdyby dany jazyk rozumne podporoval makra. Pokud nekdo nema validaci vstupu a necha probublat z formulare nenumericky vstup tam, kde je pozadovano cislo, ma mnohem vetsi problem, nez ze mu to shodilo aplikaci.

Jak víš, že tu chybu způsobil programátor, když se objektové aplikace sestavují až za běhu? Úplně stejná situace nastane, pokud uživatel otevře třeba XML s jinou strukturou. To při překladu neodchytíš. Validaci vstupu dělám až v objektu, který ten vstup má za úkol zpracovat, protože každý objekt si musí umět uhlídat vstupy. Jak bys chtěl při překladu odchytit chybu, když omylem při volání metody přehodíš dva parametry stejného typu?

Kromě toho vložit string nebo tuples do takové metody nemusí být chybou.

A ano, mas pravdu, ze v dnesnich interaktivnich systemech fakt runtime chyba obycejne nevede k ukonceni cele aplikace. Jenze problem, o kterem jsem puvodne psal, je v tom, ze (zase se opakuju) dnesni jazyky uz umeji nektere tridy chyb proste eliminovat. Ty ostatni se budto prizpusobi nebo budou v nekterych oblastech po pravu vytlaceny.

Nebudou vytlačeny. Při překladu stačí kontrola syntaxe. Zbytek je jen nadstavbou, která může být užitečná, ale není nezbytná.

[Reklama]

[Inkvizitor]

Jak víš, že tu chybu způsobil programátor, když se objektové aplikace sestavují až za běhu? Úplně stejná situace nastane, pokud uživatel otevře třeba XML s jinou strukturou. To při překladu neodchytíš. Validaci vstupu dělám až v objektu, který ten vstup má za úkol zpracovat, protože každý objekt si musí umět uhlídat vstupy. Jak bys chtěl při překladu odchytit chybu, když omylem při volání metody přehodíš dva parametry stejného typu?

Tezko bych hledal lepsi argument proti pouzivani OOP, dekuju. Co se tyce dvou parametru stejneho typu, krome specifickych pripadu (treba min a max) je mozne prohozeni dvou parametru vyresit prave tim, ze se bude pracovat s presnejsimi typy (enum namisto ciselnych konstant atd.). A jasne, logicke chyby typovy system resit neumi.

[v]

...logicke chyby typovy system resit neumi.

je to docela dobrý nástroj k jejich prevenci, už prostý newtype (typedef struct v Cčku ) dost pomůže nebo takové "units of measure" v F#

[gll]

Plugin do linteru ten problem samozrejme nevyresi lepe, je to reseni ad hoc a je to reseni z principu mene spolehlive, nez first-class podpora ve standardnich nastrojich jazyka.

Je to univerzálnější. Statická kontrola v případech s konstantním formátovacím řetězcem funguje stejně jako v Rustu. Narozdíl od Rustu funguje i kontrola v čase běhu.

[Inkvizitor]

Plugin do linteru ten problem samozrejme nevyresi lepe, je to reseni ad hoc a je to reseni z principu mene spolehlive, nez first-class podpora ve standardnich nastrojich jazyka.

Je to univerzálnější. Statická kontrola v případech s konstantním formátovacím řetězcem funguje stejně jako v Rustu. Narozdíl od Rustu funguje i kontrola v čase běhu.

Na rozdil od Pythonu Rust zadnou podobnou kontrolu v case behu nepotrebuje. A asi rozumime slovu "univerzalni" kazdy jinak, kdyz musis pro kazdou podobnou vec psat novy plugin do linteru.

[Reklama]

[Kit]

Jak víš, že tu chybu způsobil programátor, když se objektové aplikace sestavují až za běhu? Úplně stejná situace nastane, pokud uživatel otevře třeba XML s jinou strukturou. To při překladu neodchytíš. Validaci vstupu dělám až v objektu, který ten vstup má za úkol zpracovat, protože každý objekt si musí umět uhlídat vstupy. Jak bys chtěl při překladu odchytit chybu, když omylem při volání metody přehodíš dva parametry stejného typu?

Tezko bych hledal lepsi argument proti pouzivani OOP, dekuju. Co se tyce dvou parametru stejneho typu, krome specifickych pripadu (treba min a max) je mozne prohozeni dvou parametru vyresit prave tim, ze se bude pracovat s presnejsimi typy (enum namisto ciselnych konstant atd.). A jasne, logicke chyby typovy system resit neumi.

Nikdo tě nenutí OOP používat. Volné vazby mezi objekty nejsou pro každého.

Číselné konstanty ještě někdo používá? Měl jsem na mysli například výšku a hmotnost. Obojí jsou reálná čísla, ale když je přehodíš, dostaneš nesmysly. Ano, můžeš si udělat typy Výška a Hmotnost. Děláš to?

[Kit]

Na rozdil od Pythonu Rust zadnou podobnou kontrolu v case behu nepotrebuje. A asi rozumime slovu "univerzalni" kazdy jinak, kdyz musis pro kazdou podobnou vec psat novy plugin do linteru.

Kontrolu typu dat potřebuješ v obou případech. V Pythonu ji uděláš až v místě, kde ta data zpracováváš, tedy v objektu. V Rustu si je kontroluješ ještě před vstupem do modulu, aby ti tam vstoupila pouze čistá data. Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.

[BoneFlute]

Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.

Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.

[Kit]

Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.

Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.

Objektový přístup spočívá v tom, že data kontroluješ co možná nejpozději.

[BoneFlute]

Objektový přístup spočívá v tom, že data kontroluješ co možná nejpozději.

To je tvá představa o Objektovém přístupu. Doufám, že není moc rozšířená.

[operator]

Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.

Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.

Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou. Viz C, ktere lehce umozni prekladat padajic programy a naopak jsou ty typy zdrojem mnohych chyb. Pak tu jsou jazyky s pokrocilejsim typovym systemem. Pokrocilejsi = slozitejsi. Tyto sice umozni eliminovat nektere chyby typické pro C, ale a) ty se v dynamickem jazyce nevyskytuji b) je tu kardinalni otazka, kdo odladi chyby v pouziti typoveho systemu?  A na to mame univerzalni odpoved, testy. Staticke typy vec zbytecne komplikuji a ve vysledku nic neresi. S vyjimkou vykonu.

[BoneFlute]

Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou. Viz C, ktere lehce umozni prekladat padajic programy a naopak jsou ty typy zdrojem mnohych chyb. Pak tu jsou jazyky s pokrocilejsim typovym systemem. Pokrocilejsi = slozitejsi. Tyto sice umozni eliminovat nektere chyby typické pro C, ale a) ty se v dynamickem jazyce nevyskytuji b) je tu kardinalni otazka, kdo odladi chyby v pouziti typoveho systemu?  A na to mame univerzalni odpoved, testy. Staticke typy vec zbytecne komplikuji a ve vysledku nic neresi. S vyjimkou vykonu.

Tak to určitě.

[Ondra Satai Nekola]

Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.

Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.

Cele je to o tom, ze tu je sorta lidi, kteri si mysli, ze staticke typy jim odladi system. Coz je blbost nad entou.

A proc je to blbost na entou? Protoze je to straw man.

[operator]

Spor je tedy jen v tom, kdy a kde tu kontrolu uděláš - uvnitř či venku.

Ne, to ani náhodou. Spor je o to, zda data kontrolovat včas, nebo pozdě.

Objektový přístup spočívá v tom, že data kontroluješ co možná nejpozději.

To je spis dynamicky pristup a nerekl bych co nejpozdeji, ale na nejvhodnsim miste. Je to vice flexibilni, ale prave toho se nejvíc boji ti, co s tim neumi pracovat.

[Inkvizitor]

A proc je to blbost na entou? Protoze je to straw man.

Blbost na ntou je predevsim porad dokola operovat Ceckem. S Operatorem nema smysl diskutovat, vykasli se na to.