jakubův notes – programování a vejšplechty

Na začátek upozorňuji, že já se o to snažit nebudu. Nemyslím si, že bych měl dostatečný rozhled v technologiích a postupech práce s frameworky, takže to radši přenechám někomu jinému. Těsně před obědem (dva dny stará sekaná s bramborem, takže obrázek si můžete udělat sami) jsem se tak toulal v končinách Google Readeru, když tu zavadil můj zrak o kanál zdrojáku a tam trčící „Srovnání webových frameworků“. Jelikož jsem se poslední dobou rozhodoval, či vytáhnout kotvy z vod PHP a přesunout se (byť třebas jen na chvilku) někam jinam, a tam stálo, že se budou srovnávat frameworky hlavně v Javě, pak Ruky on Rails a z PHP Symfony a Zend, neváhal jsem.

Nečekal jsem, že bych se dozvěděl nějakou jednoznačnou informaci, že tenhle a tenhle framework je nejlepší, protože to a to a to. Závěr ve stylu: Každý se hodí na něco jiného, byl více než zřejmý ono to jinak ani nejde. (Stejné to máte, jako když se kohokoli soudného zeptáte, jaká distribuce Linuxu je nejlepší.) To je jedině dobře.

Ale hlavně mě zajímaly kapitoly o těch Javích frameworcích. .NET je pro mě trochu pasé, protože Mono nikdy vývoj od hochů z Microsoftu nedožene (jestli jo, tak si tenhle článek vytisknu a sním (pokud na to nezapomenu)) a mně se nechce mít kvůli vývoji mít Windows (na kterých se mi ke všemu nikdy nevyvíjelo moc dobře), když je tu Java, která je „multiplatformní“.

V tom mě ale tahle diplomka trochu zklamala. Chápu, že to nebylo jejím záměrem, ale popis byl trochu strohý. Srovnání mi nedalo, co jsem potřeboval – rozhodnutí, pro jaký framework se nakonec rozhodnout. A závěr jsem již hodnotil. Čekal jsem, že Javí frameworky na tom budou s dokumentací na dobré úrovni – nakonec dopadl nejlépe Symfony a Zend byl na třetím místě. Bylo by špatné zamlčet, že Spring byl druhý. Ale u něj zase nevidím nic nového, co by mi mohl do vědění přinést. (Dobře, znalosti Javy nejsou jen tak k zahození.) Jsem asi moc líný, abych se konečně odpoutal od PHP.

Jsem pragmatický minimalista se sklony k perfekcionismu. Když se to spojí s programováním obecně, hledám různé cesty, jak něco napsat jednodušeji a lépe. Když se to spojí s PHP, tak jsem napsal už asi 4 „frameworky“, každý z nich jednou použil a potom zahodil jako neskutečný bastl :-). Prošel jsem mnoha stádii, ale s každým jsem se snažil o více jednoduchosti. První z mých výtvorů byl nedokonalou napodobeninou Zendu a bylo utrpení s tím pracovat. Dodělal jsem s tím jednu věc a hned to letělo z disku.

[ pokračovat ve čtení… ]

Dědičnost je vyzdvihována jako jedna z největších předností objektově orientovaného programování. Je to ale dvousečná zbraň – pokud dědičnost používáte špatně, způsobí více škody, než-li přinese užitku. Já se snažím dědění vyhýbat, jak to jen jde, takže moje dědičné hierarchie nikdy neuvidíte zasahovat do nějakých extrémních hloubek, já zůstávám hezky na mělčině. Maximálně tak dvě generace a konec.

[ pokračovat ve čtení… ]

Když jsem se před dvěma dny dozvěděl, co se chystá za pěknou změnu v návrhu jmenných protorů do nové desetinkové verze PHP, do verze 5.3, říkal jsem si, že si vývojáři asi museli poplést měsíce, jelikož již dlouho, co apríl byl, a ještě daleko, než zase bude. Jedná se o jednu takovou pěknou syntaktickou libůstku – a to o oddělovač jmenných prostorů. Doposud bylo oddělovačem dvojdvojteččí (::), kteréžto se v PHP používá pro přístup k statickým třídním vlastnostem a metodám. A v tom je právě ten problém – nastaly nejednoznačnosti při volání funkcí. Jednoduchý příklad:

<?php
namespace foo::bar;
function baz()
{
    echo "function";
}

namespace foo;
class bar
{
    public static function baz()
    {
        echo "method";
    }
}

foo::bar::baz(); // function? method?

Co by se mělo správně vypsat? A je tu vlastně nějaké „správně“?

Když se člověk podívá na takové C++, tak tam se jmenné prostory oddělují pomocí dvojdvojteččí (::) a stejně se přistupuje i k třídním vlastnotem a metodám. Nikde jsem ale neviděl, že by kvůli tomu na C++ někdo nadával, protože ho toto vytrestalo. Proto jsem to zkusil:

#include <iostream>

namespace foo {
    namespace bar {
        void baz(void)
        {
            std::cout << "function" << std::endl;
        }
    }

    class bar {
        public:
            static void baz(void)
            {
                std::cout << "method" << std::endl;
            }
    };
}

int main(void)
{
    foo::bar::baz();
    return 0;
}

A co mi z toho vylezlo? g++ (verze 4.2.1) říká, že prý: Error: symbol `_ZN3foo3bar3bazEv' is already defined. Jelikož jsem chtěl, aby se mi do terminálu vypsal řetězec function, metodě bar::baz() jsem místo přázdného seznamu argumentů dal jeden celočíselný s očekáváním, že g++ najde moji fci baz(void) ve jemnném prostoru foo::bar. Chyba lávky. g++ fci nenašlo a zahlásilo, že ve třídě bar neexistuje metoda baz(void), ale nachází se zde pouze baz(int). U C++ tedy mají jasno – třída definuje svůj vlastní jmenný prostor, který dostává přednost před jmenným prostorem definovaným pomocí namespace (alespoň takto to podle všeho má implementované g++).

Ale v PHP ne. Radši zavedeme nějaký bizarní oddělovač, který se pro tento účel naprosto nehodí (to i ten smajlík, co byl v návrzích (:)), vypadá lépe :o)) – zpětné lomítko je a vždycky bylo v Céčkoidních jazycích znakem pro escapování.

Myslím, že je čas se ještě vážněji než-li do teď zabývat jinými možnostmi programování pro web a jednoduchého skriptování. Python, Ruby? (V případě omezeního se pouze na první přichází v úvahu ještě Java.)

Člověk dostává hodně zběsilých nápadů. Nedávno mě zrovna něco takového napadlo. Jak jsem četl Code Generation in Action, honilo se mi hlavou hodně myšlenek o tom, kde by se takové generování dalo v PHP a při tvorbě webu využít. Když jsem si tak probíral model třívrstvé aplikace (model, kontroler, view), tak ve view (na webu je to prakticky rovno HTML šablonám), ani v kontroléru by podle mě nebylo nějaké generování prakticky k ničemu.

Šablony člověk dostane nakódované od kodéra (v mnoha případech to znamená „předat“ si je sám sobě :o)), aplikační logiky bývá poskrovnu a to ona je většinou právě tím, co se aplikace od aplikace liší. Jedinou oblastí, kde by se generování mohlo ujmout, je model a práce s daty. (Sebeujištění se: ano, tady by to opravdu šlo.) Dneska je sice v módě, že nad daty sedí několikero runtimeových vrstev abstrakcí, ale tak jsem si říkal, což takhle „kompilovat“ model přesně na míru databázi?

Řekl bych, že opičení se po Railsovém ORM – ActiveRecordu – bylo už dost. Moc se mi líbí názory lidí, kteří obhajují tyhle druhy práce s databází tím, že je to odpoutává od toho strašného složitého SQL. Nevím, ale mě vždycky psaní SQL bavilo. Samozřejmě, že většina dotazů jsou jen rutinní výběry. Ale pokud se tyhle dotazy vygenerují rovnou, zbydou na udělání ty „hezčí“, ty, při kterých člověk opravdu něco řeší. A ty podle mě je jednodušší napsat rovnou v čístém SQL než se mořit s nějakými definicemi v objektech (nejlépe ještě přes různé fluent interfaces, ať to stojí za to; nedej bůh, aby člověk jen trochu pomyslel na strašlivé SQL :o)).

Dost řešení každé blbosti v runtimeu, jde se „kompilovat“. Jde se „kompilovat“ do PHP! :o)

Tohle spojení („zkompilovat do PHP“) zní vážně divně :o)

Zatím přemýšlím nad tím, jak nejlépe si s tím pohrát. Určitě by to mělo generovat takové základní dotazy jako výběr podle jednotlivých sloupců v tabulce, ale zároveň tam musí být možnost si napsat dotazy vlastní, které se při „kompilaci“ přechroustají a „napasují“ do interfacu modelu (nějak hezky a šikovně) – interface bych chtěl podobný, jaký je k vidění jinde, ale opravdu by se jednalo jenom o to, aby metody abstrahovaly nad vykonáváním dotazu, ne aby řešily nějaké obštrukce vůbec s jeho generováním.

Bude to sranda :o)