Příspěvky

796

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 16. 03. 2011, 12:12:54 »

Modifikace cizí knihovny je sice hnus, ale když objekty z té knihovny vytváří někdo, koho taky nemůžeš modifikovat, tak buďto ve výsledku přepíšeš celou knihovnu, nebo změníš tu jednu metodu "inplace". Tady to považuju i za bezpečnější variantu, protože procházet cizí knihovnu a hledat, který všechny metody vytvářej objekt A, přepsat je, aby vytvářely objekt B - a protože tim se změnila implementace dalších tříd, tak furt dokola....

Ale jinak souhlasím, todle je "extrémní technika" a člověk by ji měl použít pouze v extrémním případě - už jsem se ale setkal s případem, kdy kdybych ji mohl použít, tak by mi to ušetřilio dny práce.

S tím, že ochrana objektů je užitečná souhlasím, ale jde něco za něco. Někdy se to hodí a někdy je to na obtíž.

Jinak daleko důležitější vlastnost prototypových jazyků je možnost předefinovat danou metodu nikoli u třídy, ale u konkrétní instance. A to má hafo použití - kvůli každý blbině se nemusí definovat vlastní třída: notabene když chce člověk hromadu objektů, kdy každej z těch objektů má některý metody předefinovaný (různý validátory, callbacky apod.). Samozřejmě, že to jde obejít pomocí ukazatelů na funkce - ale prototypový přístup je jednodušší a čistší.
Další využití je např. u různých vyvýjejících se objektů: místo aby byl v metodě switch přes stav, tak se při změně stavu objektu změní patřičnej handler apod.

Výhody dynamických jazyků jsou, akorát člověk nesmí myslet staticky. Samozřejmě, když bude člověk v dynamickém jazyku programovat jako v pascalu, tak mu zbydou jen nevýhody.

797

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 15. 03. 2011, 20:38:34 »

Osobně víc než property se mi líbí princip automatického generování setterů/getterů pomocí anotací. Právě kvůli tomu, že se to netváří jako něco jiného.

Obzvlášť v C++, před property se např. nedá dát referenčítko, takže nahrazení proměné pomocí property není "bezpečná" věc.

798

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 15. 03. 2011, 13:47:31 »

...public const jsem myslel místo

Jenže jsou případy, kdy to z nějakého důvodu mít dokumentované nechceš (třeba právě proto, abys měl svobodu to v další verzi třídy změnit) a pak to prostě vystavit nesmíš. Proto má protected tak, jak je, smysl.
Navíc nikdy nevíš, kdy bude třeba jednoduchou vlastnost najednou nahradit komplexnější logikou (takže najednou nebude prostá proměnná stačit, protože ji např. nestihneš rozumně aktualizovat). Takže prostě z principu vystavit to jako vlastnost je špatně.

Samozřejmě, že se to v praxi často dělá, protože zabalovat každou blbinu je "zbytečná práce", nese to s sebou ale riziko toho, že si člověk přidělá práce daleko víc. Určitým řešením by byly property, to ale v tak jednoduchym jazyce jako C++ nejde udělat moc dobře zaměnitelně s s prostou hodnotou.

---

Ad úprava střev: samozřejmě, za "bezpečnost" kódu se platí. Někdy je výhodnější udělat kód bezpečnej, někdy ne. Liší se to i mj. podle metodiky vývoje a dalších hafo věcí (velikosti pracovního týmu, výši pokuty od zákazníka za chybu :-)). To, že ty to nepoužíváš (já třeba také v podstatě ne) ale neznamená, že to nemá smysl. Jen to prostě není mechanismus vhodný pro každý případ.

Co se týčen utnosti šahat do střev - pokud je knihovna kvalitně udělaná, tak by to nemělo být potřeba....

799

Vývoj / Re: hladanie urciteho adresaru a nasledne vymazanie

« kdy: 14. 03. 2011, 18:59:39 »

find / -name .recycle -exec -rm -R \{\} \; -exec mkdir \{\} \;

Ale nezastaví se to na prvnim recycle, smaže všechny.

800

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 14. 03. 2011, 18:36:27 »

Ještě doplním, že ale možná svým způsobem máš pravdu - velmi často takové vnitřní stavové proměnné, které je pak v potomku třeba modifikovat - ukazují na chybu návrhu. Daná funkcionalita pravděpodobně měla být "vyjmuta" z objektu jako samostatný podobjekt a přidaná agregací (a tedy bezpečně zapouzdřená a přitom snadno měnitelná)

801

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 14. 03. 2011, 14:47:07 »

S tim public const nemáš IMHO pravdu. Jeden z cílů, proč je to tak udělané je, aby uživatelé nepoužívali místo veřejných a zaručených metod střeva. Protože střeva se můžou klidně změnit. Používáním "nedokumentovaných" střev si zakládáš na pořádnej problém... a protected proti tomu chrání.... (nicméně někdy, např. pro účely ladění, by se to hodilo, to zas jo).

Stejně tak private má svůj smysl. Pokud máš nějakou vnitřní stavovou proměnou a chceš zajistit, aby Ti ho žádný potomek obejktu nerozbil, tak to použiješ. Něco podobného je i v o dost mladší javě (final).

Co se týče toho, co private zaručuje a nezaučuje máš pravdu, ale z tohodle pohledu v C++ nezaručuje nic vůbec nic.... Vždycky si může uživatel napsat vlastní header file.
Nicméně, ve svym headeru můžeš tudle možnost odchytit a zařvat.

802

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 14. 03. 2011, 11:57:46 »

Samozřejmě, modifikace prototypu Ti nezaručí, že to bude v další verzi knihovny fungovat tak, jako v předchozí. Ale narozdíl od modifikace zdrojového kódu máš jistotu, že tvůj patch přijde na správné místo a nemusíš pamatovat na to, že ho musíš po každém updatu aplikovat (byť to rozumně napsaný makefile může zajistit, ale to je další práce).

A i pokud se fčnost knihovny změní, tak furt izolovaně napsaná funkce má větší šanci být reusabilní, než patch, popř. se lépe zandavá do nové verze knihovny.

S tím private dosti souhlasím, i když někdy opodstatněním, pokud se píše superbezpečný kód má: zaručuje, že úpravou v potomku nemůžeš rozbít funkčnost předka. Vzhledem k tomu, že ale to vyžaduje dosti velkou analýzu toho, co všechno musí být private a navíc to jak píšeš často brání modifikacím, je zisk v drtivém počtu případů menší, než přidělaná práce.
Pokud bych ale dělal knihocvnu pro houf kodérů neumětelů, tak to může ve výsledku práci ušetřit.

803

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 14. 03. 2011, 09:35:26 »

Logiku, dlouho jsem nečetl na Rootu příspěvek, který by mě doopravdy vyděsil. Až teď ten Tvůj. 

:-) a co z toho je špatně? Vím, že třeba modifikace cizích knihoven je "nestandardní" postup, pro kterej by měl mít člověk opravdu, ale opravdu důvod - ale někdy rozumější cesta není. Nebo Ty máš nějakej návrh, jak lépe modifikovat cizí knihovny? Přijde Ti lepší varianta modifikovat přímo její kód a při příštím upgradu knihovny strávit další hodiny aplikací patche a kontrolou, že vše proběhlo tak, jak má? A nebo radši tu cizí knihovnu nepoužiješ a ztrávíš x hodin psaním jejího duplikátu?

Co máš např. proti implementaci mixings už nevím vůbec :-) A pokud nic, tak jak ho budeš implementovat v jazyce, kterej to neumí nativně? (např. javascript)?

804

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 13. 03. 2011, 15:40:58 »

Konkrétně možnost modifikovat prototyp se může hodit, když chce člověk za běhu vytvořit novou třídu (např. s předefinovanou metodou). V běžnym jazyku to asi budu řešit tak, že v bázové třídě udělám vlastnost pointer na funkci a ona metoda bude volat ten pointer - jednotlivý instance pak budou předefinovávat ten pointer. V prototypovym jazyku nadefinuju novej prototyp ("poděděnej" z bázovýho) a změnim mu tu metodu a vytvářim objekty....
Nebo k vytváření patchů ke knihovnám, kterej nechci měnit zdrojovej kód (chci případně upgradovat a zachovač fčnost patche), ale potřebuju udělat úpravu. Není to čistý, ale někdy je to nejlepší řešení. Nebo k implementaci toho, co se v ruby nazývá mixings, popř. obecně k různýmu metaprogramování.

Pak je další hromada technik, který využívaj modifikaci prototype chain - např. jednoduchej příklad je "překrytí" prototypové metody vlastní implementací, např. různé callbacky apod. To jde sice i v neprototypových jazycích, ale v prototypovejch je to daleko elegantnější.

805

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 12. 03. 2011, 13:51:04 »

Rozdíl hodně závisí na tom, jak je daná dědičnost v jazyku implementovaná. Třeba dědičnost v pythonu oproti C++ je dosti jiná.

Většinou prototypová dědičnost má výhodu oproti třídní v možnosti dynamicky měnit prototyp objektu - což je silná vlastnost, když se používá dobře (a zoufalost, když špatně), výhoda v třídní dědičnosti je silná typovost (což zpravidla vede k delšímu (musí se typy uvádět) ale méně chybovému kódu).
Ale obojí jde nějak dosáhnout i v druhém typu dědičnosti - jen to tak obvykle nebývá. 

806

Sítě / Re: Test rychlost linkové vrstvy

« kdy: 26. 02. 2011, 20:48:28 »

Overhead TCP/UDP je při velkejch paketech poměrně marginální a PC  to v pohodě zvládaj, takže klidně testup propustnost TCP/UDP vrstvy...

807

Software / Re: Jak udělat z Linux serveru Windows

« kdy: 06. 02. 2011, 17:02:46 »

Asi jedinášance je virtualizace a windowsy rozběhnout v ní. Jinak se bez KVM over IP neobejdeš.

808

Vývoj / Re: MySQL: rozdělit do dvou tabulek?

« kdy: 04. 02. 2011, 10:26:42 »

Odpověď je jednoduchá - budou se používat někdy akce přes nabídky i objednávky dohromady? Pak je dát dohromady. Nebudou? Nebo mají hodně rozdílné položky? Pak rozdělit....

V mysql máš pak ještě možnost použít engine merge, v postgresql inherited tables.

809

Software / Re: Jak nalézt soubory v adresáři (2 a více přípon)

« kdy: 03. 02. 2011, 01:51:23 »

Co použít příkaz man? Ne neslouží k hledání souborů, ale odpověď na svoji otázku bys tam našel, kdybys  sis přečet aspoň ty příkazy, nad kterejmas uvažoval...
find -name \*.mkv -or -name \*.avi

Další možnost je regex
 ls | egrep '(\.mkv$)|(\.py$)'

btw. to
find *.mkv
i
find | grep mkv$
je dosti blbina - teda ono to nějak funguje, ale úplně jinak, než pravděpodobně myslíš, i když je  výsledek takovej, jakej čekáš (proto to taky selže u dvou argumentů)...

810

Hardware / Re: Jakou vhodnou grafiku nVidia?

« kdy: 31. 01. 2011, 01:20:21 »

cokoli + accelero (+ popř. pro jistotu 120mm ventilátor na neslyšných otáčkách).