376
Vývoj / Re:Poradíte někdo s převodem funkce z pythonu do c?
« kdy: 19. 10. 2015, 16:36:29 »
A proč? K čemu to má sloužit?
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
377
Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)
« kdy: 14. 09. 2015, 17:09:04 »
kit: "Objektové jazyky na tom bývají hůř, protože když to nezvládnou zoptimalizovat při překladu, tak za běhu to už nedohoní a ten kosinus budou počítat vždy."
To bych se hádal, to jazyky s bytekódem když zjistí že je možná a vhodná "optimalizace za běhu", tak si klidně bytekód přeloží znovu pro konkrétní případ.
===
Jinak celkově debatu nechápu. Porovnávají se tu dvě řešení: s eventy a bez, a jedno z nich "se považuje" za funkcionální. Co komu brání napsat v imperativním přístupu řešení s eventy a získat tím také výhodu změn scény a tedy možnost vzniku kolizí pouze na jednom místě? IMHO ani jedno z prezentovaných řešení nijak nesouvisí s paradigmatem jazyka, v kterém ho budete implementovat.
To bych se hádal, to jazyky s bytekódem když zjistí že je možná a vhodná "optimalizace za běhu", tak si klidně bytekód přeloží znovu pro konkrétní případ.
===
Jinak celkově debatu nechápu. Porovnávají se tu dvě řešení: s eventy a bez, a jedno z nich "se považuje" za funkcionální. Co komu brání napsat v imperativním přístupu řešení s eventy a získat tím také výhodu změn scény a tedy možnost vzniku kolizí pouze na jednom místě? IMHO ani jedno z prezentovaných řešení nijak nesouvisí s paradigmatem jazyka, v kterém ho budete implementovat.
378
Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)
« kdy: 11. 09. 2015, 10:42:41 »
Prýmek: To, jak odlišuješ dědičnost od toho, co je v GO, ale záleží na definici dědičnosti. Pokud do pojmu dědičnost zahrneš duck-typing, pak to, co je v GO splňuje definici dědičnosti - umí to kachní protokol, je to kachna. S tím, že to má všechny výhody a nevýhody duck-typingu - tj. objekty umí něco navíc, co s třídní dědičností nelze a platím za to horší možností syntaktické kontroly.
---
Code reuse samozřejmě neznamená jen dědičnost. Dědičnost je jedna z metod. A ten kdo umí dědičnost a neumí jiné metody bude obhajovat dědičnost, a kdo neumí dědičnost a umí jiné metody ji bude hanit. A oba se budou hádat, že "to druhé" je cesta do pekla. Dobrý programátor prostě použije vhodně daný kontext a max si zanadává - todle by šlo v támdletom jazyku napsat elegantnějc. Já takhle střídám několik jazyků a rozstu z toho dost.
---
"To je v problému čtvercoobdélník splněno
Čtverec má dané metody obdélníka..."
Jak jsem již psal, to může a nemusí být pravda. Pokud obdélník nadefinuji jako něco, co umí změnit jednu stranu nezávisle na druhé, tak čtverec definici obdélníka prostě nesplňuje a dané metody mít nemůže.
---
Code reuse samozřejmě neznamená jen dědičnost. Dědičnost je jedna z metod. A ten kdo umí dědičnost a neumí jiné metody bude obhajovat dědičnost, a kdo neumí dědičnost a umí jiné metody ji bude hanit. A oba se budou hádat, že "to druhé" je cesta do pekla. Dobrý programátor prostě použije vhodně daný kontext a max si zanadává - todle by šlo v támdletom jazyku napsat elegantnějc. Já takhle střídám několik jazyků a rozstu z toho dost.
---
"To je v problému čtvercoobdélník splněno
Čtverec má dané metody obdélníka..."Jak jsem již psal, to může a nemusí být pravda. Pokud obdélník nadefinuji jako něco, co umí změnit jednu stranu nezávisle na druhé, tak čtverec definici obdélníka prostě nesplňuje a dané metody mít nemůže.
379
Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)
« kdy: 10. 09. 2015, 23:14:45 »
Prymek:
"To není dědičnost, ale skládání"
Ano? Čím se to liší od dědičnosti v C++? Tam také když dědíš, tak vlastně do struktury přidáš data předka - a můžeš volat metody předka a když to dáš do metody, co očekává předka, tak to funguje..... Dědičnost ve většině jazyků prakticky funguje jako kompozice s nějakým syntatickým cukrem. To, co je v GO se chová jako dědičnost a tedy podle duck typing je dědičnost :-)
---
Jinak k debatě, jestli čtevere je nebo není obdélník - tak to samozřejmě závisí na definici obdélníku. Pokud ho definujeme jako:
1) "Čtyřuhelník, který má všechny úhly pravé", pak evidentně čtverec obdélník je.
Pokud ho ovšem definujeme jako:
2) "Čtyřuhelník, který má všechny úhly pravé a může si měnit šířku a výšku."
- Pak evidentně čtverec obdélník není.
Takže záleží, pro co píšeme program a jakou definici obdélníku používáme. Dokážu si představit i řešení, kdy mám obdélník dle definice 1) a z něj podědím jak čtverec, tak obdélník dle definice 2).
"To není dědičnost, ale skládání"
Ano? Čím se to liší od dědičnosti v C++? Tam také když dědíš, tak vlastně do struktury přidáš data předka - a můžeš volat metody předka a když to dáš do metody, co očekává předka, tak to funguje..... Dědičnost ve většině jazyků prakticky funguje jako kompozice s nějakým syntatickým cukrem. To, co je v GO se chová jako dědičnost a tedy podle duck typing je dědičnost :-)
---
Jinak k debatě, jestli čtevere je nebo není obdélník - tak to samozřejmě závisí na definici obdélníku. Pokud ho definujeme jako:
1) "Čtyřuhelník, který má všechny úhly pravé", pak evidentně čtverec obdélník je.
Pokud ho ovšem definujeme jako:
2) "Čtyřuhelník, který má všechny úhly pravé a může si měnit šířku a výšku."
- Pak evidentně čtverec obdélník není.
Takže záleží, pro co píšeme program a jakou definici obdélníku používáme. Dokážu si představit i řešení, kdy mám obdélník dle definice 1) a z něj podědím jak čtverec, tak obdélník dle definice 2).
380
Software / Re:Slovník pre množné čísla a tvary slov
« kdy: 27. 07. 2015, 21:56:46 »
To co hledáš je hunspell.
381
Windows a jiné systémy / Re:Samba 4 s RSAT na Windows 8
« kdy: 16. 06. 2015, 12:22:45 »
Proč? Zkopíruju server, udělám update na kopii a když to bude funkční, tak vyměním za primár...
Pokud mam na tom železe virtualizaci, tak to ani nebude moc práce navíc a nepotřebuju další stroj...
Pokud mam na tom železe virtualizaci, tak to ani nebude moc práce navíc a nepotřebuju další stroj...
382
Sítě / Re:Jaký switch do home racku
« kdy: 07. 06. 2015, 18:34:35 »
Pájení se neboj, je to trivka :-)
383
Vývoj / Re:Prosím o radu s PHP OOP
« kdy: 15. 05. 2015, 15:08:17 »Citace
....Jo, to je přesně Javovskej protektivní přístup: někdo by to mohl používat blbě, tak to radši zakážeme.
aktivne nie ale stane sa ze ich bude citat a maintainovat po ostatnych :-))
Pokud je někdo čuník, tak je čuník, a seberestriktivnější jazyk mu nepomůže. A pokud někdo není čuník,
tak proč mu zakazovat užitečné obraty jen proto, že se s nimi dá prasit?
Jinak zakázání abstract private není konstrukce navíc, ale naopak restrikce navíc, stejně jako "devirtualizace"
private metod, z který to vychází, je opět pravidlo navíc a nikoli pravidlo namíň, takže ani ta argumentace
až tak nesedí....
384
Vývoj / Re:Prosím o radu s PHP OOP
« kdy: 15. 05. 2015, 09:54:32 »
Co je neintuitivní se možná neshodem v globálu, ale pokud by možnost předefinování privátních metod byla např. omezená na metody označené jako abstract, tak co by bylo na tom neintuitivní?
Co je neintuitivního na tom, že je možné předefinovat metodu, která je přímo označená jako "todle musíš předefinovat"?
Co je neintuitivního na tom, že je možné předefinovat metodu, která je přímo označená jako "todle musíš předefinovat"?
385
Vývoj / Re:Prosím o radu s PHP OOP
« kdy: 13. 05. 2015, 13:51:58 »
Je to případ dovedení ad absurdum, na kterém je vidět, že rozhodnutí, že to, že private metody budou nevirtuální je "zjednodušení pro kompilátor", které není intuitivní.
A které mj. vede k nemožnosti vyjádřit IMHO rozumnou myšlenku, abych zakázal volání funkce kterou musí definovat potomci, protože se vztahuje k nějaké specifické implementaci něčeho, ovšem jelikož ta funkce neudržuje objekt ve "well defined" stavu, tak by tu funkci potomci neměli mít možnost volat.
A které mj. vede k nemožnosti vyjádřit IMHO rozumnou myšlenku, abych zakázal volání funkce kterou musí definovat potomci, protože se vztahuje k nějaké specifické implementaci něčeho, ovšem jelikož ta funkce neudržuje objekt ve "well defined" stavu, tak by tu funkci potomci neměli mít možnost volat.
386
Vývoj / Re:Prosím o radu s PHP OOP
« kdy: 12. 05. 2015, 22:19:09 »
Galonek:
Jasně, že když znáš pravidla, tak to víš. Jde o to, že logickej jazyk by měl mít pravidla "intuitivní".
A jak je vidět z reakce většiny diskutujících - evidentně intuitivní nejsou....
Jasně, že když znáš pravidla, tak to víš. Jde o to, že logickej jazyk by měl mít pravidla "intuitivní".
A jak je vidět z reakce většiny diskutujících - evidentně intuitivní nejsou....
387
Vývoj / Re:Prosím o radu s PHP OOP
« kdy: 11. 05. 2015, 21:29:00 »
Jo, php v poslední době dost Javovatí. A bohužel pravidla dědičnosti si taky bere od ní....
To ještě neznamená, že to jsou pravidla logická :-).
Zkuste si schválně níže tipnout, co bude výstupem tohodle programu (bez spouštění :-)).
To ještě neznamená, že to jsou pravidla logická :-).
Zkuste si schválně níže tipnout, co bude výstupem tohodle programu (bez spouštění :-)).
Kód: [Vybrat]
public class Test {
public static void main(String[] args) {
Nested n = new Nested();
n.test();
n.print();
}
private void print() {
System.out.println("PRIVATE");
}
public static class Nested extends Test {
public void test() {
this.print();
super.print();
}
public void print() {
System.out.println("PUBLIC");
}
}
}
388
Vývoj / Re:Prosím o radu s PHP OOP
« kdy: 11. 05. 2015, 12:52:29 »
Např. v C++ to jde a není na tom nic divného.
Říkáš tím: tady mám metodu, kterou zděděné třídy mají implementovat, ale nemají ji volat.
(PS: ponechávám vedle to, že princip privátních metod je kvůli testování poněkud problematický koncept jako takový).
Říkáš tím: tady mám metodu, kterou zděděné třídy mají implementovat, ale nemají ji volat.
(PS: ponechávám vedle to, že princip privátních metod je kvůli testování poněkud problematický koncept jako takový).
389
Vývoj / Re:Prosím o radu s PHP OOP
« kdy: 11. 05. 2015, 11:47:39 »
Nevím, co tu blbnete s trolama a netvorama. Uvedenej pattern je úplně normální, akorát by pro účely dokumentace a syntax checking mělo
bejt, že třída A je označena abstract a je v ní abstraktní metoda func1. To je celé na rovině "myšlenkové".
Na rovině faktické pak má PHP zmršenej koncept dědičnosti, takže tam nejde udělat abstraktní virtuální metoda private, takže to takto udělat nejde a musí holt ta metoda bejt protected. Pokud to chceš fakt mít private, tak není jiná cesta, než tu funkcionalitu vydělit do speciální třídy a dát ji jako private membera té třídy - ale já bych se s tím neštval :-)
bejt, že třída A je označena abstract a je v ní abstraktní metoda func1. To je celé na rovině "myšlenkové".
Na rovině faktické pak má PHP zmršenej koncept dědičnosti, takže tam nejde udělat abstraktní virtuální metoda private, takže to takto udělat nejde a musí holt ta metoda bejt protected. Pokud to chceš fakt mít private, tak není jiná cesta, než tu funkcionalitu vydělit do speciální třídy a dát ji jako private membera té třídy - ale já bych se s tím neštval :-)
390
Vývoj / Re:Události s předem danou pravděpodobností
« kdy: 29. 04. 2015, 16:48:59 »
Slowthinker ma pravdu. Distribuce nejsou generatory nahodnych cisel ale obalky nad nima - a kdyz se rekne vygeneruj nahodne cislo, tak kazdy dusevne zdravy clovek, ktereho nebavi si honit ego, predpoklada pouziti generatoru nahodnych cisel - a ten uniformni proste je. Howgh.
