Rozdíl mezi návrhovými vzory Přepravka x Obálka x Holder

[Kit]

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.

[Reklama]

[gl]

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.

[Kit]

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

[Mirek Prýmek]

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.

[gl]

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.

[Reklama]

[Kit]

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().

[zboj]

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í).

[hawran diskuse]

    

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?

[gl]

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.

[gl]

   

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.