Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Martin9 19. 07. 2016, 12:20:35
-
Učím se programovat v Javě a chtěl bych se zeptat, zda je nějaký rozdíl mezi těmito návrhovými vzory.
-
Jazyk sis vybral nejlepší možný. Na vzory se zatím vykašli, pokud se teprve učíš. Většinou se s nima setkáš jen u pohovorů a ve škole. V reálu je lepší si osahat nějaké, které se používají u frameworků. Až budeš něco umět, tak je více oceníš a zároveň poznáš, že většinou je to jen na honění ega.
-
Na školách se učí vzory, protože z nich lze snadno zkoušet. Analytické dovednosti pro reálné projekty reálných zákazníků by pro pedagogy byly oříšek.
-
To stejné je s matikou. Učí se věty a důkazy místo matiky. Naneštěstí je to pak u pohovorů úplně stejné. Takže vzory se hodí na to, aby ses dostal k lopatám a ještě tě měly za řízka :D
-
Na školách se učí vzory, protože z nich lze snadno zkoušet. Analytické dovednosti pro reálné projekty reálných zákazníků by pro pedagogy byly oříšek.
To je dost zjednodusujici.
Samozrejme, ze v praxi potrebujes o dost vic, nez znat jazyk a vzory. Ale to neznamena, ze jsou ti k nicemu.
A ano, skolni priklady jsou, to je ale prekvapeni (!), snazsi nez ulohy realneho sveta. Mozna protoze nejdriv musis studentum dat zaklady.
-
Se vzorem Přepravka (Messenger) se setkáš docela často. Význam zbývajících dvou mi uniká, i když je docela možné, že je intuitivně používám. Není nutné znát všechny vzory.
-
To stejné je s matikou. Učí se věty a důkazy místo matiky. Naneštěstí je to pak u pohovorů úplně stejné. Takže vzory se hodí na to, aby ses dostal k lopatám a ještě tě měly za řízka :D
Než začneš řešit nějaký matematický problém, je dobré znát dokázané věty z dané oblasti, abys neřešil něco co už bylo vyřešeno. Studiem důkazů se naučíš postupy používané v dané oblasti. Pokud to nechápeš, jsi lopata ty.
-
Matematika není o používání už naučeného, ale právě o trénování myšlení a nových problémech. To ale lopatě nevysvětlím, že jo.
-
Matematika není o používání už naučeného, ale právě o trénování myšlení a nových problémech. To ale lopatě nevysvětlím, že jo.
Proč vůbec existuje matematická literatura, když každý může začít sám od nuly?
-
Jak ta otázka souvisí s naším problémem? Na VŠ bys měl začít tím, že řešíte matematické problémy a znalosti se postupně přidají. Ono je to přesně naopak a problémy se nikdy řešit nezačnou. Pro lopaty je to fajn, ale pro ostatní ztráta času.
-
Na školách se učí vzory, protože z nich lze snadno zkoušet. Analytické dovednosti pro reálné projekty reálných zákazníků by pro pedagogy byly oříšek.
Vzory se učí, protože jsou užitečné.
-
javaman nepozna ani jeden navrhovy vzor, preto to oznacuje za zbytocnost. A opat nezabudol napisat slovo - lopata :D. Ale uz sme sa dozvedeli, ze aj ucit sa matematiku je zbytocne, pretoze pouzivat uz nieco existujuce je nieco pre lopaty. Javamana, preco si sa teda ucil na zakladnej skole, ako vypocitat obsah stvorca? Vymysli nieco sam, ako to spravit, pretoze pouzit nieco existujuce s=a^2 to je pod tvoju uroven ;D
-
..., ako vypocitat obsah stvorca? Vymysli nieco sam, ako to spravit, pretoze pouzit nieco existujuce s=a^2 to je pod tvoju uroven ;D
Proč by si měl pamatovat takové vzorečky, když na to stačí Runge-Kutta 2. řádu? :D
-
Javamane, jak zjistíš časový posun dvou zašumělých signálů ze senzoru, pokud máš SNR 5dB? Zkus to odvodit a začni definicí sčítání.
-
Na školách se učí vzory, protože z nich lze snadno zkoušet. Analytické dovednosti pro reálné projekty reálných zákazníků by pro pedagogy byly oříšek.
Vzory se učí, protože jsou užitečné.
Vzory jsou užitečné nejen pro samotné použití, ale i pro usnadnění komunikace mezi programátory. Když někomu řeknu, že tam má dát NullObject realizovaný Singletonem, tak by měl vědět, co po něm chci.
-
Účel některých návrhových vzorů jsem také nikdy nepochopil. Proč například používat Singleton namísto statických tříd?
-
Účel některých návrhových vzorů jsem také nikdy nepochopil. Proč například používat Singleton namísto statických tříd?
Proč používat statické třídy místo Singletonu? Proč používat Singleton jinde než v NullObject?
-
Účel některých návrhových vzorů jsem také nikdy nepochopil. Proč například používat Singleton namísto statických tříd?
Ještě jednoduchá odpověď: Statická třída se nedá injektovat, což je její obrovské mínus.
-
Účel některých návrhových vzorů jsem také nikdy nepochopil. Proč například používat Singleton namísto statických tříd?
Ještě jednoduchá odpověď: Statická třída se nedá injektovat, což je její obrovské mínus.
Určitě tohle nejde řešit pomocí nějakých dynamických importů? (Javu neznám)
-
Ked mas staticku triedu, uz mas v dalsom kode zadrotovanu zavislost na konkretnych statickych metodach. Singleton trieda stale moze dedit od nejakych rozhrani. Takze to, ze je je tam nejaky sngleton vobec nemusis vsade tahat.
-
Účel některých návrhových vzorů jsem také nikdy nepochopil. Proč například používat Singleton namísto statických tříd?
Proč používat statické třídy místo Singletonu? Proč používat Singleton jinde než v NullObject?
Co je to za nesmysl?
-
Účel některých návrhových vzorů jsem také nikdy nepochopil. Proč například používat Singleton namísto statických tříd?
Ještě jednoduchá odpověď: Statická třída se nedá injektovat, což je její obrovské mínus.
Určitě tohle nejde řešit pomocí nějakých dynamických importů? (Javu neznám)
Daleko jednodušší je vyrobit instanci a tu injektovat.
-
Účel některých návrhových vzorů jsem také nikdy nepochopil. Proč například používat Singleton namísto statických tříd?
Proč používat statické třídy místo Singletonu? Proč používat Singleton jinde než v NullObject?
Co je to za nesmysl?
+1
-
javaman dal sam sebe +1. Pozor na neho, to bude schizofrenik! Co sa tyka Singletonu, tak splna principy OOP, co nemozno povedat o statickej triede.
-
Účel některých návrhových vzorů jsem také nikdy nepochopil. Proč například používat Singleton namísto statických tříd?
Proč používat statické třídy místo Singletonu? Proč používat Singleton jinde než v NullObject?
Co je to za nesmysl?
+1
Vy jste dva?
-
Ked mas staticku triedu, uz mas v dalsom kode zadrotovanu zavislost na konkretnych statickych metodach. Singleton trieda stale moze dedit od nejakych rozhrani. Takze to, ze je je tam nejaky sngleton vobec nemusis vsade tahat.
On se ani Singleton nemusí všude tahat. Zatím jediné rozumné použití jsem našel právě v NullObject. V ostatních případech se jednoduše použije jedna standardní instance třídy.
-
V ostatních případech se jednoduše použije jedna standardní instance třídy.
Normálně se tomu říká singleton :D Ale to je jasný, že ty máš svoje názvosloví, abys mohl trollit.
-
Co sa tyka Singletonu, tak splna principy OOP, co nemozno povedat o statickej triede.
Nevýhodou Singletonu je, že se nedá použít standardní operátor new, neboť konstruktor je privátní. Je také docela problém mu předat nějaké parametry, například přihlašovací údaje pro připojení k databázi.
-
Ak by si hocikto vytvoril objekt, uz by to moc single nebolo. Je to ciel a zakladna vlastnost.
Atributy objektu nastavis ake chces. Xyz.getInstance().setAbc(...)
-
Ak by si hocikto vytvoril objekt, uz by to moc single nebolo. Je to ciel a zakladna vlastnost.
Atributy objektu nastavis ake chces. Xyz.getInstance().setAbc(...)
Zrovna u té databáze ten objekt může vytvořit jen ten, kdo zná přístupová práva. A to jen v jediné třídě celé aplikace. Zároveň mi to nezabrání otevřít 3 různé databáze a pracovat s nimi.
Gettery ani settery nepoužívám. Myslel jsem si, že to víš.
-
Co sa tyka Singletonu, tak splna principy OOP, co nemozno povedat o statickej triede.
Nevýhodou Singletonu je, že se nedá použít standardní operátor new, neboť konstruktor je privátní. Je také docela problém mu předat nějaké parametry, například přihlašovací údaje pro připojení k databázi.
Proč by mi proboha mělo vadit že nemůžu použít new? Singleton přeci má vytvořit (včetně jeho nakonfigurování) dependency injection framework (např. Spring odjakživa nebo EJB od Java EE 6), s tím se přeci snad už v dnešní době nikdo nedělá ručně!
-
On Kit totiž neumí programovat a plácá pátý přes devátý. Ale věřim, že děti ve škole mu to žerou, protože se u toho tváří cool. Sem tam naschvál splete pojmy, aby dodal na magičnosti svých vět :D
-
Co sa tyka Singletonu, tak splna principy OOP, co nemozno povedat o statickej triede.
Nevýhodou Singletonu je, že se nedá použít standardní operátor new, neboť konstruktor je privátní. Je také docela problém mu předat nějaké parametry, například přihlašovací údaje pro připojení k databázi.
Proč by mi proboha mělo vadit že nemůžu použít new? Singleton přeci má vytvořit (včetně jeho nakonfigurování) dependency injection framework (např. Spring odjakživa nebo EJB od Java EE 6), s tím se přeci snad už v dnešní době nikdo nedělá ručně!
Proč ti vadí, když operátor new používám? Proč ti vadí, že Singleton (až na výjimky viz výše) jednoduše nepotřebuji a přesto mám jistotu, že instance bude právě jedna?
-
Proč by mi proboha mělo vadit že nemůžu použít new? Singleton přeci má vytvořit (včetně jeho nakonfigurování) dependency injection framework (např. Spring odjakživa nebo EJB od Java EE 6), s tím se přeci snad už v dnešní době nikdo nedělá ručně!
Proč ti vadí, když operátor new používám? Proč ti vadí, že Singleton (až na výjimky viz výše) jednoduše nepotřebuji a přesto mám jistotu, že instance bude právě jedna?
Nemá smysl znovu vymýšlet co už je vymyšlené. Sice může být zajímavé si všechno programovat sám, ale aby člověk byl v praxi použitelný jako součást týmu tak musí dodržovat standardy. Když si nějaký objekt udělám pomocí new tak mám zodpovědnost za to že ho i správně nakonfiguruji (nejspíš parametry konstruktoru nebo settery), správně ho inicializuji (až poté co budou nakonfigurované a inicializované všechny jeho závislosti) a nakonec udělám správně shutdown (dřív než shutdown všech jeho závislostí). Dělat se s tímhle na každém projektu znovu a znovu je příšerně neefektivní a vytvoří to spoustu špatně udržovatelného kódu, proto vznikly standardizované postupy jak na to. Nejrozšířenější je asi Spring Framework nebo novější verze Java EE (EJB).
-
Ohledně toho singletonu, já ho pochopil a přišel mu na chuť až po hodně dlouhé době, asi nakonec i celé OOP vezmu na milost, pokud budou existovat i další povedené vzory, jako je Signleton: https://www.malts.com/en-ca/our-whisky-collection/the-singleton/
-
Nemá smysl znovu vymýšlet co už je vymyšlené. Sice může být zajímavé si všechno programovat sám, ale aby člověk byl v praxi použitelný jako součást týmu tak musí dodržovat standardy. Když si nějaký objekt udělám pomocí new tak mám zodpovědnost za to že ho i správně nakonfiguruji (nejspíš parametry konstruktoru nebo settery), správně ho inicializuji (až poté co budou nakonfigurované a inicializované všechny jeho závislosti) a nakonec udělám správně shutdown (dřív než shutdown všech jeho závislostí). Dělat se s tímhle na každém projektu znovu a znovu je příšerně neefektivní a vytvoří to spoustu špatně udržovatelného kódu, proto vznikly standardizované postupy jak na to. Nejrozšířenější je asi Spring Framework nebo novější verze Java EE (EJB).
A kdo říká, že vymýšlím vymyšlené? Používám přesně to, co je vymyšlené. Dependency Injection. Vzor Singleton k tomu nepotřebuji.
Pokud vytvořím objekt pomocí operátoru new, je již nakonfigurován. Nevytvářím nevalidní objekty. Je na to dostatek běžných vzorů, jejichž použití je triviální. Běžně je kopíruji mezi projekty, zpravidla ani nepotřebují úpravy. Je to velmi snadno udržovatelné, neboť je to velmi štíhlé a stabilní.
-
;D
-
Radši zůstanu lopatou a budu používat jazyky kde podobné problémy neexistují.
-
Radši zůstanu lopatou a budu používat jazyky kde podobné problémy neexistují.
Ktoré sú to jazyky?
-
A kdo říká, že vymýšlím vymyšlené? Používám přesně to, co je vymyšlené. Dependency Injection. Vzor Singleton k tomu nepotřebuji.
Ked nieco nepotrebujes, tak to nepouzivaj. Ja nepouzivam Flyweight a nepotentujem sa z toho. Nemam proti nemu nic osobne, proste som neriesil problem, kde by sa to hodil.
Aspon trochu k veci: sucastou kazdeho vzoru je to, aky problem riesi a v akom kontexte je mozne ho pouzit. Z tohoto sa treba odpichnut. Bohuzial by som uvital anglicku terminologiu. Nem tudom, mi ez a "přepravka"?
-
Radši zůstanu lopatou a budu používat jazyky kde podobné problémy neexistují.
Ktoré sú to jazyky?
Většina dynamických jazyků. například http://mishadoff.com/blog/clojure-design-patterns/ (http://mishadoff.com/blog/clojure-design-patterns/)
-
A kdo říká, že vymýšlím vymyšlené? Používám přesně to, co je vymyšlené. Dependency Injection. Vzor Singleton k tomu nepotřebuji.
Ked nieco nepotrebujes, tak to nepouzivaj. Ja nepouzivam Flyweight a nepotentujem sa z toho. Nemam proti nemu nic osobne, proste som neriesil problem, kde by sa to hodil.
Aspon trochu k veci: sucastou kazdeho vzoru je to, aky problem riesi a v akom kontexte je mozne ho pouzit. Z tohoto sa treba odpichnut. Bohuzial by som uvital anglicku terminologiu. Nem tudom, mi ez a "přepravka"?
Flyweight je skutečně jen na speciální věci, protože utíká od myšlenky OOP. Někdy je však výkonová optimalizace nutná. Pokud ho programátor použije s vědomím, že je to v podstatě procedurální záležitost, je to OK.
Pod pojmem Přepravka se skrývá vzor Messenger. Používám ho velmi často pro prezentaci dat objektu ve strukturované podobě. Mnohé základní knihovny produkují Messenger jako jedinou možnost získání dat z objektu. Je to velmi praktické a rychlé.
-
Radši zůstanu lopatou a budu používat jazyky kde podobné problémy neexistují.
Stačí vzít nějaký funkcionální, tam je jen jeden návrhový vzor - monáda. Ta se dá naroubovat na všechno (dobře, trochu přeháním, ale ne moc). OOP je v tomto docela zmatek.
-
Radši zůstanu lopatou a budu používat jazyky kde podobné problémy neexistují.
Stačí vzít nějaký funkcionální, tam je jen jeden návrhový vzor - monáda. Ta se dá naroubovat na všechno (dobře, trochu přeháním, ale ne moc). OOP je v tomto docela zmatek.
Nutnost používání monád je také problém, který v jiných jazycích neexistuje.
-
Radši zůstanu lopatou a budu používat jazyky kde podobné problémy neexistují.
Stačí vzít nějaký funkcionální, tam je jen jeden návrhový vzor - monáda. Ta se dá naroubovat na všechno (dobře, trochu přeháním, ale ne moc). OOP je v tomto docela zmatek.
Však on se časem najde nějaký blb, který tohle nebude vědět a další návrhové vzory tam udělá! :D
-
Účel některých návrhových vzorů jsem také nikdy nepochopil. Proč například používat Singleton namísto statických tříd?
Jazyky které používají terminologii statické metody typicky nemají metatřídy (a hlavně nemají metody a fieldy tříd) a Singleton se implementuje jako normální instance která se někde drží v globální proměnné ("statický field"). To ale rozhodně není jediná možná implementace singletonu a už vůbec to není smysl singletonu!
V jazycích které mají metatřídy (přesněji: mají metody a field/atributy třídy) a je možné použít přímo třídu, protože ta vlastně je singleton.
Omlouvám se pokud to zní zmateně, bohužel si nejsem vědom že by tady existovala jednodná terminologie.
-
nieco ohladom Singletonu http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons (http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons)
kazdopadne ho pouzivam aj ja
-
Dobre som sa pobavil, len tak dalej ;-)
Tyhle Singletony a OOP každého jenom otravují. Já bych všechny ty internety a počítače zakázala.
-
Radši zůstanu lopatou a budu používat jazyky kde podobné problémy neexistují.
Stačí vzít nějaký funkcionální, tam je jen jeden návrhový vzor - monáda. Ta se dá naroubovat na všechno (dobře, trochu přeháním, ale ne moc). OOP je v tomto docela zmatek.
Nutnost používání monád je také problém, který v jiných jazycích neexistuje.
V čem to je problém?
-
Účel některých návrhových vzorů jsem také nikdy nepochopil. Proč například používat Singleton namísto statických tříd?
Jazyky které používají terminologii statické metody typicky nemají metatřídy (a hlavně nemají metody a fieldy tříd) a Singleton se implementuje jako normální instance která se někde drží v globální proměnné ("statický field"). To ale rozhodně není jediná možná implementace singletonu a už vůbec to není smysl singletonu!
V jazycích které mají metatřídy (přesněji: mají metody a field/atributy třídy) a je možné použít přímo třídu, protože ta vlastně je singleton.
Omlouvám se pokud to zní zmateně, bohužel si nejsem vědom že by tady existovala jednodná terminologie.
Proč vlastně používat třídu? Nestačí globální proměnná?
-
Radši zůstanu lopatou a budu používat jazyky kde podobné problémy neexistují.
Stačí vzít nějaký funkcionální, tam je jen jeden návrhový vzor - monáda. Ta se dá naroubovat na všechno (dobře, trochu přeháním, ale ne moc). OOP je v tomto docela zmatek.
Nutnost používání monád je také problém, který v jiných jazycích neexistuje.
V čem to je problém?
Před měsícem zde byla diskuze o mutable datových strukturách v haskellu. Ta diskuze byla dost dlouhá. Tahle diskuze o singletonech je dost podobná. Kdykoliv jazyk nutí dodržování nějakého paradigmatu, přináší to problémy.
-
Radši zůstanu lopatou a budu používat jazyky kde podobné problémy neexistují.
Stačí vzít nějaký funkcionální, tam je jen jeden návrhový vzor - monáda. Ta se dá naroubovat na všechno (dobře, trochu přeháním, ale ne moc). OOP je v tomto docela zmatek.
Nutnost používání monád je také problém, který v jiných jazycích neexistuje.
V čem to je problém?
Před měsícem zde byla diskuze o mutable datových strukturách v haskellu. Ta diskuze byla dost dlouhá. Tahle diskuze o singletonech je dost podobná. Kdykoliv jazyk nutí dodržování nějakého paradigmatu, přináší to problémy.
Larry?
-
Larry?
Kdo je Larry?
-
Larry?
Kdo je Larry?
Nejspis rok 1987 z https://james-iry.blogspot.cz/2009/05/brief-incomplete-and-mostly-wrong.html ?
-
Larry?
Kdo je Larry?
Nejspis rok 1987 z https://james-iry.blogspot.cz/2009/05/brief-incomplete-and-mostly-wrong.html ?
To má být vtipné? Perl vznikl pro řešení reálných úproblémů. Narozdíl od vašich jazyků, které uměle vytváří problémy nové.
-
Larry?
Kdo je Larry?
Nejspis rok 1987 z https://james-iry.blogspot.cz/2009/05/brief-incomplete-and-mostly-wrong.html ?
To má být vtipné? Perl vznikl pro řešení reálných úproblémů. Narozdíl od vašich jazyků, které uměle vytváří problémy nové.
to je pravda, stejně jako třeba PHP nebo COBOL, ty nevytvářejí nové problémy uměle, ale zcela přirozeně
-
Larry?
Kdo je Larry?
Nejspis rok 1987 z https://james-iry.blogspot.cz/2009/05/brief-incomplete-and-mostly-wrong.html ?
To má být vtipné? Perl vznikl pro řešení reálných úproblémů. Narozdíl od vašich jazyků, které uměle vytváří problémy nové.
to je pravda, stejně jako třeba PHP nebo COBOL, ty nevytvářejí nové problémy uměle, ale zcela přirozeně
COBOL neznám. PHP slouží svému účelu dobře.
-
Larry?
Kdo je Larry?
Nejspis rok 1987 z https://james-iry.blogspot.cz/2009/05/brief-incomplete-and-mostly-wrong.html ?
To má být vtipné? Perl vznikl pro řešení reálných úproblémů. Narozdíl od vašich jazyků, které uměle vytváří problémy nové.
to je pravda, stejně jako třeba PHP nebo COBOL, ty nevytvářejí nové problémy uměle, ale zcela přirozeně
COBOL neznám. PHP slouží svému účelu dobře.
který jazyk svému účelu dobře neslouží?
-
To má být vtipné? Perl vznikl pro řešení reálných úproblémů. Narozdíl od vašich jazyků, které uměle vytváří problémy nové.
Ano, je to vtipne. Cely text.
-
Larry?
Kdo je Larry?
Nejspis rok 1987 z https://james-iry.blogspot.cz/2009/05/brief-incomplete-and-mostly-wrong.html ?
To má být vtipné? Perl vznikl pro řešení reálných úproblémů. Narozdíl od vašich jazyků, které uměle vytváří problémy nové.
to je pravda, stejně jako třeba PHP nebo COBOL, ty nevytvářejí nové problémy uměle, ale zcela přirozeně
COBOL neznám. PHP slouží svému účelu dobře.
který jazyk svému účelu dobře neslouží?
Většina jazyků nemá svůj jasný účel jako PHP.
-
Většina jazyků nemá svůj jasný účel jako PHP.
"snadno dostat uzivatele na Daily WTF"?
-
Radši zůstanu lopatou a budu používat jazyky kde podobné problémy neexistují.
Stačí vzít nějaký funkcionální, tam je jen jeden návrhový vzor - monáda. Ta se dá naroubovat na všechno (dobře, trochu přeháním, ale ne moc). OOP je v tomto docela zmatek.
No ;)
https://www.packtpub.com/application-development/haskell-design-patterns
-
COBOL neznám. PHP slouží svému účelu dobře.
COBOL je dnes už za zenitem, v podstatě se v něm jen udržují běžící aplikace.
PHP svému účelu slouží velmi dobře. Bohužel někteří lidé nepochopili, jak se v něm dá elegantně programovat a tak jim zbývá jen na tento jazyk plivat všude, kudy chodí.
Ostatně každý jazyk má své příznivce i odpůrce.
-
Většina jazyků nemá svůj jasný účel jako PHP.
"snadno dostat uzivatele na Daily WTF"?
Jaký je účel Javy? Java se používá na vše a přitom se na spoustu věcí nehodí. Neříkám, že je PHP dokonalé, ale weby se v tom dělají snadno. Zkuste v Javě pracovat s delšími SQL dotazy nebo key value strukturami. Nelíbí se mi hlavně OOP inspirované Javou. Nemožnost monkey patchingu atd. Naštěstí PHP nikomu nevnucuje jedno jediné paradigma a spousta knihoven OOP nepoužívá.
-
Java se hodí na úplně všechno. Proto je tak oblíbená. Nemusíš vůbec střídat jazyky, když ji máš.
Monkey patching chybí :D OK.
-
Java se hodí na úplně všechno. Proto je tak oblíbená. Nemusíš vůbec střídat jazyky, když ji máš.
Monkey patching chybí :D OK.
Nechybí jen monkey patching, ale celkově možnost přepsat existující funkci. runkit pokud vím v novějších verzích nefunguje.
-
Jak to asi ty frameworky dělají, když to nejde...
Za prvé je to prasárna, proto tam není přímá podpora a za druhé to není problém, pokud po tom hodně toužíš a máš velmi dobrý důvod.
-
Java se hodí na úplně všechno. Proto je tak oblíbená. Nemusíš vůbec střídat jazyky, když ji máš.
Monkey patching chybí :D OK.
No to jsi pak dost omezeny.
-
Jak to asi ty frameworky dělají, když to nejde...
Za prvé je to prasárna, proto tam není přímá podpora a za druhé to není problém, pokud po tom hodně toužíš a máš velmi dobrý důvod.
Mluvíš o PHP? Jaký PHP framework tohle dělá?
Slovo prasárna nemám rád.
-
COBOL neznám. PHP slouží svému účelu dobře.
COBOL je dnes už za zenitem, v podstatě se v něm jen udržují běžící aplikace.
PHP svému účelu slouží velmi dobře. Bohužel někteří lidé nepochopili, jak se v něm dá elegantně programovat a tak jim zbývá jen na tento jazyk plivat všude, kudy chodí.
Ostatně každý jazyk má své příznivce i odpůrce.
Za zenitem je i Java, byť se to někomu nemusí líbit. Z příslušných diskusí nakonec vyplyne jedině to, že většina lidi neví, co to je zenit.
-
Jo ták. Mluvil jsem o dokonalé Javě. PHP je zbytečný vůbec používat, když máš Javu.
PHP je celkově prasárna, takže by sis na to měl zvyknout.
Za zenitem je i Java, byť se to někomu nemusí líbit. Z příslušných diskusí nakonec vyplyne jedině to, že většina lidi neví, co to je zenit.
Tak určitě :D
-
PHP je celkově prasárna, takže by sis na to měl zvyknout.
PHP nepoužívám, tak si nemusím zvykat. Jak jsem psal výše, na PHP mi vadí, že se snaží zakazovat užitečné featury (ty jim říkáš prasárny).
-
Kdybys používal luxusní jazyk, tak bys je tam měl, jen dobře schované před lopatami.
-
Kdybys používal luxusní jazyk, tak bys je tam měl, jen dobře schované před lopatami.
To je nevýhoda jazyků určených pro lopaty.
-
javaman:
Jo tak java je luxusny jazyk? Ako vyvojar s 6 rocnou praxou v Jave a 7 rocnou praxou v C#/.NETe mozem s istotou povedat, ze luxusny jazyk je skor C#, ako Java. Jedina nevyhoda je platforma, ale uz aj to sa meni nakolko vysiel .NET Core 1.0. Keby si bol naozaj guru, tak nerobis v jave, ale C/C++ a ASM. Vies java ma vela kniznic uz hotovych, ty ako NElopata by si si mal vsetko pisat sam. Nechapem ale potom, preco pouzivas Javu :D
-
javaman:
Jo tak java je luxusny jazyk? Ako vyvojar s 6 rocnou praxou v Jave a 7 rocnou praxou v C#/.NETe mozem s istotou povedat, ze luxusny jazyk je skor C#, ako Java. Jedina nevyhoda je platforma, ale uz aj to sa meni nakolko vysiel .NET Core 1.0. Keby si bol naozaj guru, tak nerobis v jave, ale C/C++ a ASM. Vies java ma vela kniznic uz hotovych, ty ako NElopata by si si mal vsetko pisat sam. Nechapem ale potom, preco pouzivas Javu :D
Podle téhle definice je nelopat ještě mín než podle javamana.
-
To ma tesi, ze nas je este menej :). Ale javaman je troll, takze jemu netreba nic verit. Ani obycajny bubble sort nevedel napisat, ktory od neho chcel jeden z diskutujucich. Povedal, ze to je pre lopaty. On by mal pouzit lopatu na tie hovna co tu vysral v diskusiach.
-
Nutnost používání monád je také problém, který v jiných jazycích neexistuje.
Monády nejsou problém, monády jsou řešení. Velice efektivní způsob, jak pomocí vysoké abstrakce řešit spoustu rozdílných věcí jednotným způsobem. "Být monádou" je vlastnost nějaké struktury (ta struktura splňuje "monadické zákony") - buď tyto abstraktní vlastnosti umíš využít pomocí obecného kódu, nebo neumíš. Když neumíš, je to vždycky horší, ne lepší.
Třeba ty mnou už x-krát zmíněné promisy v JS taky monadické zákony splňují, ale JS nemá pořádný aparát na práci s obecnou monadickou strukturou. X let zkoušeli dělat asynchronní věci přes callbacky, až je konečně napadlo použít monadický přístup. Ale bohužel ad hoc, ne obecně.
Žádná "nutnost" používání monád ani v Haskellu není. Ale je to asi nejefektivnější způsob, jak spoustu různých problémů vyřešit pomocí jedné abstrakce.
Je to jako bys měl spešl fci mapint na mapování fce přes integery a spešl mapstr pro mapování přes stringy. Není to zbytečný? Není lepší použít jednotnou abstrakci "mapuju přes jakýkoli typ, který funkce přijímá jako parametr"? S monádama je to přesně stejný. Nemusíš je používat, ale byla by to veliká hloupost, pokud to jazyk umožňuje.
-
javaman:
Jo tak java je luxusny jazyk? Ako vyvojar s 6 rocnou praxou v Jave a 7 rocnou praxou v C#/.NETe mozem s istotou povedat, ze luxusny jazyk je skor C#, ako Java. Jedina nevyhoda je platforma, ale uz aj to sa meni nakolko vysiel .NET Core 1.0. Keby si bol naozaj guru, tak nerobis v jave, ale C/C++ a ASM. Vies java ma vela kniznic uz hotovych, ty ako NElopata by si si mal vsetko pisat sam. Nechapem ale potom, preco pouzivas Javu :D
Nekrmme prosím trolly
-
Nutnost používání monád je také problém, který v jiných jazycích neexistuje.
Monády nejsou problém, monády jsou řešení. Velice efektivní způsob, jak pomocí vysoké abstrakce řešit spoustu rozdílných věcí jednotným způsobem. "Být monádou" je vlastnost nějaké struktury (ta struktura splňuje "monadické zákony") - buď tyto abstraktní vlastnosti umíš využít pomocí obecného kódu, nebo neumíš. Když neumíš, je to vždycky horší, ne lepší.
Třeba ty mnou už x-krát zmíněné promisy v JS taky monadické zákony splňují, ale JS nemá pořádný aparát na práci s obecnou monadickou strukturou. X let zkoušeli dělat asynchronní věci přes callbacky, až je konečně napadlo použít monadický přístup. Ale bohužel ad hoc, ne obecně.
Žádná "nutnost" používání monád ani v Haskellu není. Ale je to asi nejefektivnější způsob, jak spoustu různých problémů vyřešit pomocí jedné abstrakce.
Je to jako bys měl spešl fci mapint na mapování fce přes integery a spešl mapstr pro mapování přes stringy. Není to zbytečný? Není lepší použít jednotnou abstrakci "mapuju přes jakýkoli typ, který funkce přijímá jako parametr"? S monádama je to přesně stejný. Nemusíš je používat, ale byla by to veliká hloupost, pokud to jazyk umožňuje.
Co je míněno tou absencí aparátu? Mám za to, že v každém dynamickém jazyce, tedy i v JS, není obecná implementace monád problém.
-
PHP nepoužívám, tak si nemusím zvykat. Jak jsem psal výše, na PHP mi vadí, že se snaží zakazovat užitečné featury (ty jim říkáš prasárny).
Které užitečné featury ti nové PHP zakázalo? Osobně nic nepostrádám. Možná proto, je jsem zvyklý psát skripty tak, jak se psát mají.
-
Java se hodí na úplně všechno. Proto je tak oblíbená. Nemusíš vůbec střídat jazyky, když ji máš.
Monkey patching chybí :D OK.
Výýýýýborně, takže mi velmi rád řekneš, jak v javě napíšeš OS, že? Hlavně mě zajímá ta část, jak bez JVM zavedeš javou JVM, aby jsi mohl vůbec použít javu a potom by mě zajímal low lewel přístup k HW při psaní ovladačů. A další téma k zamyšlení, jak budeš programovat v javě třeba pro ATmega 48/88/168? Nebo ta java není zase tak dokonalá, jak se nám snažíš říct?
-
PHP nepoužívám, tak si nemusím zvykat. Jak jsem psal výše, na PHP mi vadí, že se snaží zakazovat užitečné featury (ty jim říkáš prasárny).
Které užitečné featury ti nové PHP zakázalo? Osobně nic nepostrádám. Možná proto, je jsem zvyklý psát skripty tak, jak se psát mají.
Ne, že by mi to vyloženě chybělo, ale občas jsem narazil na situaci, kdy by se mi hodilo něco dynamicky změnit a v PHP to nešlo. Například ta situace s injektováním singletonů o které jsi psal výše, by možná šla vyřešit pouhým přepsáním některých funkcí. Asi to není úplně správný způsob, ale proč to zakazovat.
-
Teoreticky nic nebrání vytvoit VM přímo pro dané železo bez nutnosti použít jiný OS. Někde jsem četl, že takto fungují i jisté odnože Smalltalku, kdy Smalltalkovský VM běží přímo na daném železe bez podpory nějakého OS a na něm už jen Smalltalk.
Krom jsou k dispozici i Java kompilátory do nativního kódu/binárky dané platformy.
Mimochodem, existuje speciální odnož Javy pro real time aplikace.
...jak budeš programovat v javě třeba pro ATmega...
Že by nějak takto?
http://www.harbaum.org/till/nanovm/index.shtml
Takže v Javě se dá dělat opravdu všechno.
-
mozno mozes, ale bude to stat za hovno, presne akoo stoji aj javaman. Btw. staci sa pozriet na tie javovske aplikacie, SQL Developer. To si teda neviem predstavit, ako by vyzeral OS pisany v Jave. To by musel byt ozaj vtip a firma, ktora by to robila, by si strelila do kolena :D
-
PHP nepoužívám, tak si nemusím zvykat. Jak jsem psal výše, na PHP mi vadí, že se snaží zakazovat užitečné featury (ty jim říkáš prasárny).
Které užitečné featury ti nové PHP zakázalo? Osobně nic nepostrádám. Možná proto, je jsem zvyklý psát skripty tak, jak se psát mají.
Ne, že by mi to vyloženě chybělo, ale občas jsem narazil na situaci, kdy by se mi hodilo něco dynamicky změnit a v PHP to nešlo. Například ta situace s injektováním singletonů o které jsi psal výše, by možná šla vyřešit pouhým přepsáním některých funkcí. Asi to není úplně správný způsob, ale proč to zakazovat.
Singleton se v PHP dá napsat i jako funkce, která se následně dá injektovat. Nevýhodu vidím jen v tom, že to přidá další WTF do aplikace, což považuji za nežádoucí.
V PHP se toho dá dynamicky změnit hodně. Obvykle jen stačí podívat se na problém z trochu odlišného úhlu. Pokud by sis přesně vzpomněl, co ti scházelo, můžeme to prodiskutovat třeba v jiném vlákně. Mnoho problémů se dá elegantně vyřešit použitím polymorfismu.
-
Teoreticky nic nebrání vytvoit VM přímo pro dané železo bez nutnosti použít jiný OS. Někde jsem četl, že takto fungují i jisté odnože Smalltalku, kdy Smalltalkovský VM běží přímo na daném železe bez podpory nějakého OS a na něm už jen Smalltalk.
Krom jsou k dispozici i Java kompilátory do nativního kódu/binárky dané platformy.
Mimochodem, existuje speciální odnož Javy pro real time aplikace.
...jak budeš programovat v javě třeba pro ATmega...
Že by nějak takto?
http://www.harbaum.org/till/nanovm/index.shtml
Takže v Javě se dá dělat opravdu všechno.
Ano, teoreticky můžu udělat HW, u kterého přesunu JVM do ROM a po postu už bude java použitelná, ale to nevypovídá nic o použitelnosti javy na cokoliv, ale o možnosti zprasit cokoliv. Mimochodem, podobně bych mohl jednoduše do ROM vrazit třeba interpreter perlu a tvrdit, že perl umí všechno. Ostatně, spousta 8bitů obsahovala v ROM Basic, který byl ihned použitelný, ale nikdo si asi dnes nedovolí tvrdit, že je Basic univerzální nejlepší jazyk. Ale dobrá, pokud je java na všechno, tak to upřesním, chci ten OS napsat pro standardní x86(64), aby si jej mohl kdokoliv nainstalovat a nemusel kvůli tomu hackovat HW.
What the NanoVM is and what it isn't
It is not a full featured Java VM and it will never be. It will always be limited to a small subset of the java language and the standard java libraries and a few application specific methods. Furthermore, it is not meant to replace C as the standard way of programming microcontrollers. It is less flexible and has a lower performance than C or assembler programs.
Realita je taková, že jediné dva způsoby, které jsou univerzální zcela na cokoliv, co daný HW umožňuje, jsou strojový kód a assembler. Nicméně to neznamená, že jsou na všechno nejvhodnější - například portace mezi platformami znamenají v podstatě vše přepsat. Stejně jako není univerzálně nejvhodnější java, ani žádný jiný jazyk. Kdyby totiž takový jazyk byl, nikdo by neměl důvod, ani potřebu, používat cokoliv jiného. A světe div se, jazyků existují stovky, možná tisíce, každý byl vytvořený za nějakým účelem, některé jsou úlet, některé se na některé úkoly hodí víc, na některé míň, něco v nich nemusí být vůbec možné a světe div se, ani jejich autoři snad nikdy nebyli tak debilní, aby prohlásili, že ten jejich je nejlepší, nejuniverzálnější a vše ostatní je zbytečný crap.
-
mozno mozes, ale bude to stat za hovno, presne akoo stoji aj javaman. Btw. staci sa pozriet na tie javovske aplikacie, SQL Developer. To si teda neviem predstavit, ako by vyzeral OS pisany v Jave. To by musel byt ozaj vtip a firma, ktora by to robila, by si strelila do kolena :D
SQL developer je jedna z mých nejzamilovanějších aplikací, díky ní jsem se opravdu naučil Oraclí syntaxe, abych mohl dělat v SQL*plus a nemusel tu java zrůdnost vůbec spouštět :D
-
Realita je taková, že jediné dva způsoby, které jsou univerzální zcela na cokoliv, co daný HW umožňuje, jsou strojový kód a assembler. Nicméně to neznamená, že jsou na všechno nejvhodnější - například portace mezi platformami znamenají v podstatě vše přepsat. Stejně jako není univerzálně nejvhodnější java, ani žádný jiný jazyk. Kdyby totiž takový jazyk byl, nikdo by neměl důvod, ani potřebu, používat cokoliv jiného. A světe div se, jazyků existují stovky, možná tisíce, každý byl vytvořený za nějakým účelem, některé jsou úlet, některé se na některé úkoly hodí víc, na některé míň, něco v nich nemusí být vůbec možné a světe div se, ani jejich autoři snad nikdy nebyli tak debilní, aby prohlásili, že ten jejich je nejlepší, nejuniverzálnější a vše ostatní je zbytečný crap.
Ještě existuje pár jazyků s tak minimalistickou VM, že se dají vypálit do BIOSu. Basic patřil k těm méně povedeným, ale fungoval a svého času v něm byla napsána hromada aplikací. Dále zmíněný Smalltalk, který ukazuje, že i v minimalistickém jazyce se dá programovat objektově. Forth se dodnes používá k programování jednočipů, Lisp se zase ukázal výhodným pro umělou inteligenci. Kdo by se dnes patlal se zdrojákem v Assembleru, který má již popsané nevýhody, když si může vybrat nějakou VM a na ní programovat mnohem pohodlněji?
-
Ještě existuje pár jazyků s tak minimalistickou VM, že se dají vypálit do BIOSu. Basic patřil k těm méně povedeným, ale fungoval a svého času v něm byla napsána hromada aplikací. Dále zmíněný Smalltalk, který ukazuje, že i v minimalistickém jazyce se dá programovat objektově. Forth se dodnes používá k programování jednočipů, Lisp se zase ukázal výhodným pro umělou inteligenci. Kdo by se dnes patlal se zdrojákem v Assembleru, který má již popsané nevýhody, když si může vybrat nějakou VM a na ní programovat mnohem pohodlněji?
Kdo by se patlal s assemblerem... kdokoliv, kdo potřebuje naplno využít možnosti a výkon daného HW, přičemž nemusí psát v asm celou aplikaci, ale pouze kritické části? Ale nejde ani o to, kdo se s čím chce patlat, ale o to, jestli je java (případně jakýkoliv jiný jazyk) použitelný a dokonce nejlepší (nevím, co to má znamenat, já si pod tím představuji především efektivitu vývoje i běhu) na jakýkoliv úkol. Něco takového si myslím nemůže o žádném jazyku prohlásit nikdo příčetný, kdo má alespoň hrubou představu o tom, o čem mluví.
-
Kdo by se patlal s assemblerem... kdokoliv, kdo potřebuje naplno využít možnosti a výkon daného HW, přičemž nemusí psát v asm celou aplikaci, ale pouze kritické části? Ale nejde ani o to, kdo se s čím chce patlat, ale o to, jestli je java (případně jakýkoliv jiný jazyk) použitelný a dokonce nejlepší (nevím, co to má znamenat, já si pod tím představuji především efektivitu vývoje i běhu) na jakýkoliv úkol. Něco takového si myslím nemůže o žádném jazyku prohlásit nikdo příčetný, kdo má alespoň hrubou představu o tom, o čem mluví.
Například v Lispu je obvyklé, že části, ve kterých je třeba naplno využít možností daného HW, se prostě v tom Assembleru (nebo C) napíší a stanou se součástí toho vyššího jazyka. Výsledek je pak rychlý, současně snadno udržovatelný a dokonce modifikovatelný za běhu.
-
PHP nepoužívám, tak si nemusím zvykat. Jak jsem psal výše, na PHP mi vadí, že se snaží zakazovat užitečné featury (ty jim říkáš prasárny).
Které užitečné featury ti nové PHP zakázalo? Osobně nic nepostrádám. Možná proto, je jsem zvyklý psát skripty tak, jak se psát mají.
Ne, že by mi to vyloženě chybělo, ale občas jsem narazil na situaci, kdy by se mi hodilo něco dynamicky změnit a v PHP to nešlo. Například ta situace s injektováním singletonů o které jsi psal výše, by možná šla vyřešit pouhým přepsáním některých funkcí. Asi to není úplně správný způsob, ale proč to zakazovat.
Singleton se v PHP dá napsat i jako funkce, která se následně dá injektovat. Nevýhodu vidím jen v tom, že to přidá další WTF do aplikace, což považuji za nežádoucí.
V PHP se toho dá dynamicky změnit hodně. Obvykle jen stačí podívat se na problém z trochu odlišného úhlu. Pokud by sis přesně vzpomněl, co ti scházelo, můžeme to prodiskutovat třeba v jiném vlákně. Mnoho problémů se dá elegantně vyřešit použitím polymorfismu.
Například, wrappery funkcí. Všechno k čemu se v pythonu používají dekorátory funkcí a tříd. Nebo například v testech mohu chtít přepsat nějakou funkci, kterou knihovna vnitřně používá pro nějakou IO operaci. Pro modifikaci tříd se dědění nedá použít, pokud chci aby nová třída měla stejný název jako stará. Jsou to spíš jen drobnosti. Rozhodně to není důvod proč nepoužívat PHP.
-
V PHP se toho dá dynamicky změnit hodně. Obvykle jen stačí podívat se na problém z trochu odlišného úhlu. Pokud by sis přesně vzpomněl, co ti scházelo, můžeme to prodiskutovat třeba v jiném vlákně. Mnoho problémů se dá elegantně vyřešit použitím polymorfismu.
Například, wrappery funkcí. Všechno k čemu se v pythonu používají dekorátory funkcí a tříd. Nebo například v testech mohu chtít přepsat nějakou funkci, kterou knihovna vnitřně používá pro nějakou IO operaci. Pro modifikaci tříd se dědění nedá použít, pokud chci aby nová třída měla stejný název jako stará. Jsou to spíš jen drobnosti. Rozhodně to není důvod proč nepoužívat PHP.
Wrappery se dají udělat pomocí magických metod. Jistě, je to jiné než v Pythonu, ale podporované to je.
Testy mě donutily vykopat takové IO operace ven ze tříd. Připadá mi to praktičtější než je překrývat při testování.
Nová třída může mít stejný název jako třída, ze které dědíš. Stačí použít jiný namespace. Jen mi poněkud uniká, proč bych měl chtít mít třídu-potomka se stejným názvem jako rodiče. Vidím to jen jako potenciální zdroj problémů, resp. WTF.
Netvrdím, že tohle je jediný správný postup, ale spíš ukazuji na snadnou řešitelnost takových problémů.
-
Mám za to, že v každém dynamickém jazyce, tedy i v JS, není obecná implementace monád problém.
V nějaké podobě určitě jo, ale když tam není ta typová kontrola, tak to dost postrádá tu eleganci :) ... degraduje to pak na celkem prostý skládání funkcí, přičemž složenina možná bude fungovat a možná vyhodí nějakou obskurní výjimku někde uprostřed :) Na těch promises v JS je to vidět dobře.
-
V PHP se toho dá dynamicky změnit hodně. Obvykle jen stačí podívat se na problém z trochu odlišného úhlu. Pokud by sis přesně vzpomněl, co ti scházelo, můžeme to prodiskutovat třeba v jiném vlákně. Mnoho problémů se dá elegantně vyřešit použitím polymorfismu.
Například, wrappery funkcí. Všechno k čemu se v pythonu používají dekorátory funkcí a tříd. Nebo například v testech mohu chtít přepsat nějakou funkci, kterou knihovna vnitřně používá pro nějakou IO operaci. Pro modifikaci tříd se dědění nedá použít, pokud chci aby nová třída měla stejný název jako stará. Jsou to spíš jen drobnosti. Rozhodně to není důvod proč nepoužívat PHP.
Wrappery se dají udělat pomocí magických metod. Jistě, je to jiné než v Pythonu, ale podporované to je.
Testy mě donutily vykopat takové IO operace ven ze tříd. Připadá mi to praktičtější než je překrývat při testování.
Nová třída může mít stejný název jako třída, ze které dědíš. Stačí použít jiný namespace. Jen mi poněkud uniká, proč bych měl chtít mít třídu-potomka se stejným názvem jako rodiče. Vidím to jen jako potenciální zdroj problémů, resp. WTF.
Netvrdím, že tohle je jediný správný postup, ale spíš ukazuji na snadnou řešitelnost takových problémů.
Většinou se to využije při práci s cizím kódem. Příklad: Máš nějakou knihovnu, která komunikuje po síti. Funkce v té knihovně na mnoha místech volají nějakou funkci send(data). Ty můžeš tu funkci send obalit nějakým wrapperem, který bude logovat ta posílaná data. To vše bez zásahu do kódu té knihovny, který může být mimo verzovací systém nebo někde v /usr/lib/. Vše to můžeš udělat interaktivně v REPLu při osahávání té knihovny.
-
Wrappery se dají udělat pomocí magických metod. Jistě, je to jiné než v Pythonu, ale podporované to je.
Většinou se to využije při práci s cizím kódem. Příklad: Máš nějakou knihovnu, která komunikuje po síti. Funkce v té knihovně na mnoha místech volají nějakou funkci send(data). Ty můžeš tu funkci send obalit nějakým wrapperem, který bude logovat ta posílaná data. To vše bez zásahu do kódu té knihovny, který může být mimo verzovací systém nebo někde v /usr/lib/. Vše to můžeš udělat interaktivně v REPLu při osahávání té knihovny.
Aha, tohle asi nemá jednoduché univerzální řešení. Možná snad override_function().
-
Mám za to, že v každém dynamickém jazyce, tedy i v JS, není obecná implementace monád problém.
V nějaké podobě určitě jo, ale když tam není ta typová kontrola, tak to dost postrádá tu eleganci :) ... degraduje to pak na celkem prostý skládání funkcí, přičemž složenina možná bude fungovat a možná vyhodí nějakou obskurní výjimku někde uprostřed :) Na těch promises v JS je to vidět dobře.
Jasně, kontrola tam pak nebude. Já měl spíš ma mysli, že jde obecně implementovat join pomocí bind apod. pro libovolný objekt splňující monadické axiomy. Jako relativně dobrý kompromis mi přijdou monády v Go (statické typování + rozhraní).
-
;D ;D ;D
Pořád jedny a ty samé známé* firmy.
* Na to samé, tisíckrát omleté téma.
Tak co, kdo ho má většího po tomto kole?
-
Wrappery se dají udělat pomocí magických metod. Jistě, je to jiné než v Pythonu, ale podporované to je.
Většinou se to využije při práci s cizím kódem. Příklad: Máš nějakou knihovnu, která komunikuje po síti. Funkce v té knihovně na mnoha místech volají nějakou funkci send(data). Ty můžeš tu funkci send obalit nějakým wrapperem, který bude logovat ta posílaná data. To vše bez zásahu do kódu té knihovny, který může být mimo verzovací systém nebo někde v /usr/lib/. Vše to můžeš udělat interaktivně v REPLu při osahávání té knihovny.
Aha, tohle asi nemá jednoduché univerzální řešení. Možná snad override_function().
Asi by to šlo. Teď nemám možnost to vyzkoušet.
-
;D ;D ;D
Pořád jedny a ty samé známé* firmy.
* Na to samé, tisíckrát omleté téma.
Tak co, kdo ho má většího po tomto kole?
Narozdíl od diskuzí o výši platu jsem se z téhle diskuze dověděl něco nového.