c

31.10.2010 03:51 | xxx | poslední úprava: 7.10.2011 19:56

.        

Komentáře

[Miloslav Ponkrác]

Prozradím Vám jedno sladké tajemství. Nenajdete žádný ideální jazyk. Je to smutné, ale takový je život.

Vy už nevíte, co byste zkritizoval. Nejdříve básníte o nějakém ideálním OOP, seženete všechny běsy ze statických i dynamických jazyků, splantáte všechno dohromady.

Pro jakého čerta si potřebujete zvolit, zda je metoda virtuální? Kromě honění pikosekund to k ničemu nepotřebujete – tedy se u většiny skutečných OOP jazyků se vám takové volby nedostane. A Vy to ještě zatlučete tím, že toto musí mít každý OOP jazyk.

Jinak možná jste to nepostřehnul, ale PHP je dynamicky typovaný jazyk. Stejně jako třeba Python, Ruby, Lisp, Smalltalk, Objective-C, JavaScript a obrovská spousta jazyků. Většina čistějších OOP bývá fynamicky typována už z principu.

Dynamicky typovaný jazyk všechno řeší za běhu. Včetně metod a property. Půlka věcí co tu chcete je, že jste si pod vlivem alkoholu spletl vlastnosti staticky a dynamicky typovaných jazyků.

[________________]

Všetko čo som tu spomenul obsahuje napr C#.

>>Pro jakého čerta si potřebujete zvolit, zda je metoda virtuální? Kromě honění pikosekund to k ničemu nepotřebujete – tedy se u většiny skutečných OOP jazyků se vám takové volby nedostane.

U vačšiny? U vačšiny mainstreamových jazykov(C++, C#, Visual Basic, Pascal / Delphi) si môžem zvoliť či bude metóda virtuálna. Jediné mainstramové OO jazyky ktoré túto možnosť nepodporujú sú Java a PHP. Potrebujem to kôli tomu aby som mohol zamedziť tomu aby iný developer moju metódu v inom objekte prepísal aj v rodičovskej triede. Sú prípady keď to neni vhodné. Predsa objekt je čierna skrinka a ja ako developer určujem ako s ňou môžu ostatní developeri zaobchádzať, ja povolujem čo sa s mojou triedou môže a nemôže robiť predsa to je jeden zo základnych pilierov OOP. Je to dôležité kôli bezpečnosti, a udržaťelnosti kódu, ak takúto možnosť nemám tak je to mínus.

[janik]

>>Pro jakého čerta si potřebujete zvolit, zda je metoda virtuální? Kromě honění pikosekund to k ničemu nepotřebujete – tedy se u většiny skutečných OOP jazyků se vám takové volby nedostane.

U vačšiny? U vačšiny mainstreamových jazykov(C++, C#, Visual Basic, Pascal / Delphi) si môžem zvoliť či bude metóda virtuálna.

Asi to bude tym, ze vyraz "skutocne OOP jazyky" a vyraz "mainstreamove jazyky" oznacuju disjunktne mnoziny.

[________________]

A čo je teda prvý OO jazyk? A čo je kritériom jeho pravosti? Smalltalk? Keď sme už pritom prvý OO jazyk bola Simula 67 a tá sa viac podobá na mainstreamové OO jazyky ako na nejaký Smalltalk, ktorý sa v praxi medzi developermi moc neujal.

[pht]

Smalltalk, ktorý sa v praxi medzi developermi moc neujal.

Spousta old school věcí je ve smalltalku. Navíc lekce naučené ve smalltalku tak nějak daly směr moderním OO jazykům.

[pht]

nemožnosť zvoliť či má byť metóda virtuálna (všetky metódy sú defaultne virtuálne)

+

Potrebujem to kôli tomu aby som mohol zamedziť tomu aby iný developer moju metódu v inom objekte prepísal aj v rodičovskej triede.

Tohle nějak nechápu. Pokud jsou všechny virtuální tak nepotřebujete nic označovat. Spíš by Vás mělo trápit že si nemůžete označit která *není* virtuální. Ale proč byste to dělal?

Jinak...

je to neobjektové, neprehľadné a neintuitívne a a každá PHP knižničná funkcia má iné poradie parametrov.

Tohle mě sere taky, nechápu kterej magor to takhle udělal.

Nepište o PHP dlouhé články, ale vykašlete se na něj. A na všechny deriváty na něm postavené (drupal...) taky.

[Chytrex]

Ach jo, brečíš na špatném hrobě.. PHP nebyl původně zamýšlen jako OOP jazyk.. To dobastlili až posléze.. Nevím tedy proč si stěžuješ.. Navíc PHP a bezpečnost?:) úsměvná představa.. PHP je pouze bastl který pomáhá v rychlejším nabastlení webu. Víc bych v tom nehledal.. Pokud bys v něm nehledal taky víc než to je, ušetřil bys čtvrthodinu pláče:)

[Michal Vyskočil]

Jediné mainstramové OO jazyky ktoré túto možnosť nepodporujú sú Java a PHP. Potrebujem to kôli tomu aby som mohol zamedziť tomu aby iný developer moju metódu v inom objekte prepísal aj v rodičovskej triede.

Pokud se to pochopil správně, jde vám o to, aby vaše metody nebyly předefinovatelné v potomkovi. Na to existuje klíčové slovo final.

[ffrr]

"Jediné mainstramové OO jazyky ktoré túto možnosť nepodporujú sú Java a PHP." - To, ze Java nepozna keyword virtual, neznamena, ze si nemozes zvolit, ci je dana metoda virtualna - o com inom by bolo klucove slovo final? V C# su vsetky metody implicitne non-virtual, v pripade Javy je to naopak (co moze byt predmetom zurivych optimalizacnych debat) - ale nie je pravda, ze to Java nepodporuje.

[________________]

>>Kromě honění pikosekund to k ničemu nepotřebujete

lenže tých pár milisekúnd sa zvykne nazbierať a preto potrebujeme stále výkonnejšie počítače lebo väčšina dnešných programátorov rozmýšľa ako vy.

[janik]

Pouzivanim C# ziskate uurcite tie milisekundy nazad. Ked chcete rychlost, piste weby v C. Ja radsej volim prehladnost kodu.

[Arnošt Málek]

Pokud potrebujes honit milisekundy, neprogramuj objektove, ale v co nejnizsim jazyce ... takze minimalne C, nebo asembler, pripadne rovnou ve strojaku

Rychlejsi a vykonejsi pocitace potrebujem i kvuli OOP ... protoze programatori "zleniveli" a pisou hur nez driv. Mimo jine peknym prikladem je prave objektove programovani. Je to mocny nastroj, ale mel by se pouzivat s rozumem. Je spousta veci, kde pouzivat objekty je zbytecne.

Mimochodem, tohle ja taky pekny nesmysl:

k sa snažíte v PHP programovať objektovo (čo je nutnosť ak chcete mať elegantný, bezpečný kód)

Elegantni a bezpecny kod absolutne nema zadnou souvislost s objektovym programovanim ...

[Marek Bernát]

Pokud potrebujes honit milisekundy, neprogramuj objektove, ale v co nejnizsim jazyce ... takze minimalne C, nebo asembler, pripadne rovnou ve strojaku

Skutočne? Ono už to C býva občas rýchlejšie ako assembler, ak máte agresívne optimalizujúci kompilátor. Vo vyšších jazykoch sa dá dosiahnuť ešte vyššie zrýchlenie, vďaka kope sémantických informácií, ktoré kompilátor má k dispozícií, ale Vy ich pochopiteľne nevidíte (ak sa Vám teda nechce preliezať milión riadkov kódu...) Samozrejme sa bavíme o jazykoch aspoň trochu orientovaných na rýchlosť (Lisp, rodina ML, Haskell), kde sa dajú často dosiahnuť lepšie výsledky ako s C, hoci je kód vysokoúrovňový.

[Arnošt Málek]

Ano, to mate pravdu. Ale vychazel jsem z toho, ze se bavime o "normalnich" aplikacich. A tady bych opravdu po takovych jazycich nesahal. Ne ze by neslo napsat ucetnictvi treba v Lispu, ono by slo napsat treba i v Texu, ale je to dobry napad ?

[Marek Bernát]

Normálne aplikácie? To sú ktoré? A prečo si myslíte, že v Haskelle a Lispe sa "normálne" aplikácie (nech už je to čokoľvek) netvoria?

[frEon]

Ne ze by neslo napsat ucetnictvi treba v Lispu, ono by slo napsat treba i v Texu, ale je to dobry napad

V Texu ne, ale v lispu urcite. A delalo by se to dobre.

[Josef Kufner]

V TeXu by to šlo. Byla by to neskutečná obluda, ale šlo by to.

[frEon]

ja vim, ja mluvil o tom, jestli to je, nebo neni dobry napad...

[________________]

neni všetko čiernobiele, treba nájsť rozumný kompromis medzi efektivitou a časom / cenou vývoja. ale mám pocit že ja ten kompromis ale vidím niekde inde ako vy.

>>Elegantni a bezpecny kod absolutne nema zadnou souvislost s objektovym programovanim ...

čiastočne to spolu súvisí aj keď súvislosť určite neni absolútna.

[Matlák]

Určitě souvisí. Ovšem člověk co neumí napsat přehledný procedurální kód, nedokáže o moc přehledněji psát z objekty.
<joke>Jo a s intellisense apod. kravinami pro princezny na hrášku jdi někam tady vládne vim!</joke>

[Chytrex]

+1 ta první část..:)

[Heron]

lenže tých pár milisekúnd sa zvykne nazbierať a preto potrebujeme stále výkonnejšie počítače lebo väčšina dnešných programátorov rozmýšľa ako vy

Přečti si co se píše v nějaké 30 let staré knížce o programování a optimalizacích .

[JS]

Common Lisp neni striktne dynamicky typovany - typy promennych se tam daji deklarovat (pomoci declare). Common Lisp je asi nejbliz idealu, protoze se da doprogramovat na cokoliv. I kdyz je dost veci, ktere me v nem chybi, ale ty zatim nema asi zadny jazyk.

[.]

S OOP nic spolecneho nema: psani identifikatoru jako $this (ktere jednoznacne identifikuje cil volani); definice viditelnosti (ktere napr brani serializaci a casto existuje zpusob jak to obejit); vnorene tridy; staticka typova kontrola; vyraz virtualni metoda (to je navic v primem rozporu s polymorfismem); partial classes (zneprehlednuji kod a jsou spise v rozporu s oop); jmenne prostory a syntakticky cukr jako properties. Tak se mi zda, jestli ty si na objektoveho programatora jenom nehrajes, kdyz takove veci nevis.

[sidik]

V objektovom jazyku sa to rieši takto:

if (string.Contains("PHP sux!"))

V PHP takto:

if (preg_match("/PHP sux/", $string))

Moc často se jinde nevrtám ale $this-> z PHP jsem viděl třeba v Qt jako this-> nebo u MS jazyků jako me., takže nevidím rozdíl... Prostě to tak je.

Třeba v C# jsem viděl naprosto otřesný způsob jak se připojit k databázi. V PHP stačí zavolat tři funkce, v C# ten človíček vytvářel nějakou podivnost aby to přinutil pracovat.

[________________]

Jasné že aj v iných jazykoch máš keyword this ale používaš ho len vtedy keď ho naozaj potrebuješ.

Class
{

    private a = "x";

    public void foo1(string a = "y")
    {
        return this.a; // vráti hodnotu x
    }

    public void foo1(string a = "y")
    {
        return a; // vráti hodnotu y
    }

}

[________________]

oprava:

Class
{

    private string a = "x";

    public string foo1(string a = "y")
    {
        return this.a; // vráti hodnotu x
    }

    public string foo1(string a = "y")
    {
        return a; // vráti hodnotu y
    }

}

ospravedlňujem sa som nevyspatý.

[Extak]

Mě například vyhovuje styl psaní se $this, které jednoznačně identifikuje kontext a v jiných jazycích potom marně hledám lokální proměnné, které jsou ve skutečnosti properties a naopak. Takovýto argument použít jako hodnocení jazyka neschvaluji.

[disorder]

zoznam sa s pythonom

[AraxoN]

Majú to niektorí ľudia problémy... Tak ten jazyk nepoužívaj, keď sa Ti nepáči. Či?

[________________]

Musím :( keby som mal na výber tak PHP nepoužívam vôbec.

[Milan Lajtoš]

Zbav sa PHPčka, nech to stojí koľko chce - predĺžiš si život.

[Matlák]

+1 PHP je hrůza, a OOP v PHP je hrůza^2. Měl jsem tu čest vidět (při řešení problému s tím...) cosi co dodělává objektové chování, implementované v PHP pro PHP , jedním slovem HNUS.

[frEon]

vidis. a treba takovej clos je v lispu taky napsanej pro lisp a je to maximalne luxusni zalezitost. Ale je pravda, ze lisp narozdil od php pocita s tim, ze jazyk se rozsiruje smerem k vyslednemu programu, takze vysledek tomu odpovida...

[Marek Bernát]

+1

[blizzy]

Na výběr je vždycky. Pokud to, co píšeš opravdu nepřekousneš, piš v něčem jiném, např. v C# je možné dělat webové aplikace na velmi slušné úrovni.

Většina věcí, které jsi vypsal mi v PHP vadí taky, možná až na ty properties a povinný $this, s tím jsem nikdy problém neměl. Konkrétně jsem zvyklý psát ono redundantní this i v jiných objektově orientovaných jazycích, např. C++, mám prostě radši, když na první pohled vím, v jakém kontextu je proměnná deklarovaná (a neuznávám konvence typu m_variable), je to věc osobního stylu.

I přestože je v PHP hodně věcí špatných (způsobeno hlavně dlouhou historií PHP, zpětnou kompatibilitou a leností vývojářů), tak se v PHP dá psát vcelku slušný a dobrý kód, viz např. Doctrine 2 nebo Nette Framework.

[R]

V PHP som robil niekolko mensich veci. Vzdy to bolo bez objektov a nikdy som sa na PHP nestazoval.

[Kvakor]

Ano, v PHP, stejně jako v jeho "ideovém předku" C/C++ sice objekty jsou, ale až dostatečně naroubované a tudíž ve srovnání s "přirozeně-objektovými" jazyky poměrně obludné. Tak to prostě je. Pokud nepíšete objektové programy, tak je to putna a budou vám vadit úplně jiné věci (např. to, že knihovny vypadají jako něco, co vařili Pejsek s Kočičkou).

[retroslava]

To že PHP ve verzi 4 (a následně ve verzi 5 vylepšeně) umožnilo definovat třídy a vytvářet jejich instance neznamená že je to objektově orientovaný jazyk.

Pokud hledáte nějáký plně objektově orientovaný jazyk pro web, tak můžu z vlastní zkušenosti doporučit Ruby. Jiné jako C#, Python jsem nikdy nepoužíval, tak nevím jak to chodí tam.

Ovšem i některé vaše nářeky z blogu nad implementaci objektů v PHP plně objektově orientovaný jazyk Ruby nesplňuje (jako třeba hledání klíčového slova final). A podle mne je to jenom dobře. I tak se to ale dá obejít, protože Ruby je opravdu dynamický jazyk. Pokud chcete vědět více.

Argument že musíte pracovat v PHP a že byste rád dělal v jiném jazyce sem ani nepište. Jste určitě svobodný člověk a práci si můžete najít klidně jinde, kde vám to bude vyhovovat. A argument typu 'hosting je jen pro PHP u nás' bych sem taky netahal. Jestli to s PHP opravdu myslíte vážně, tak určitě používáte PEAR a PECL (nač znovu objevovat kolo). A ukažte mi jak moc ho PHP hostingy podporují ? Ano, PHP hosting je velmi u nás levný a lehce dostupný. Ale stejně časem najdete omezení, které vyřeší buď plno časů zbytečného programování nebo několik nepříjemných telefonátu na podporu či přechod na vlastní server (třeba VPS za pár káblí se dá taky sehnat) a najmutí sysadmina.

Pokud chcete být PHP programátorem, musíte se naučit ten jazyk plně používat a navrhovat kód tak, aby přesně na ten jazyk seděl. Né navrhovat kód pro uplně jiný jazyk při návrhu a pak tu logiku přenášet při programování do PHP a stěžovat si, že to nejde.

[YYY]

V PHP se da dobre prasit, ale lze v nem psat kvalitni kod. Stejne jako v ostatnich jazycich. Zadny jazyk neni dokonaly a vzdycky je to o cloveku...

[Marek Bernát]

Vždycky je to o človeku? Takže aspoň v princípe sa podľa teba dá rozumne programovať v Brainfucku? Alebo v PHP...

[okbob]

Přesně tak to je. Neznám jazyk ve kterém by se nedalo prasit. Stejně jako se někdo nenaučí psát v přirozeném jazyku, tak se někdo nenaučí psát v programovacím jazyku - pokud někdo nad ním nestojí s bičem v ruce :)

[Marek Bernát]

Ja tiež nepoznám jazyk, v ktorom by sa nedalo prasiť, ale zároveň poznám kopu jazykov, v ktorých sa dá neprasiť. Brainfuck k nim ale nepatrí určite a PHP dosť možno tiež nie

[YYY]

Ucel brainfucku je pobavit. Ale i v brainfucku se da prasit vice nez normalne. Btw mozna je povest php dana tim, ze k nemu vice tihnou prasici nez k ostatnim jazykum.

[Grunt]

čo je nutnosť ak chcete mať elegantný, bezpečný kód

A teď prosím tu o karkulce. Jinak ten matroš bych chtěl zkusit taky. Dodnes jsem nepochopil, jestli jako fakt a nebo jde o povedenou parodii. Pokud jde o parodii tak jednoznačně *THUMBS UP*.

[Gilhad]

Asi tak :) Taky jsem napsal par veci, ktere mely kod naprosto bezpecny, elegantni a pouziti objektu by je jen zbytecne zatemnilo a zpomalilo, aniz by prineslo jakoukoli rozumnou kvalitu. (Pouziti objektu rozhodne neni kvalita sama o sobe.)

[Grunt]

Já hlavně do dnešního dne nepochopil k čemu je to vlastně vůbec dobré. A dost se bojím toho, že jednoho dne na to přijdu (stejně jako se v ráji idealismu jednoho dne vynořil ITčkař).

[Gilhad]

No me uz se na par veci objektu docela hodily, protoze se to s nimi dalo popsat trochu prehledneji, nez bez nich. Pokud clovek objekty pouziva a nenecha se jimi tupe ovladat, tak je to jeden z moznych nastroju, jak si usnadnit reseni nekterych problemu. (ale nikoli jen jediny nastroj a nikoli vsech problemu, samozrejme).

Napriklad delam soft, kde se ve vysledku hrajou ruzne pisnicky, zvuky a hlasky, pricemz jejich vyber je obcas dost slozity. Takze se mi hodilo mit pro ruzne druhy popisu vyberu samostatne objekty, ktere vsechny mely metodu VratZvuk(), ktera vratila objekt Zvuk (ci spis jeho potomka), ktery se umel prehrat.

Misto abych mel funce prehrej_mp3(soubor, offset, delka, zacatek...), prehrej_wav(soubor, offset, delka, zacatek...), prehrej_ogg(soubor, offset, delka, zacatek...) atd atd a vsude mozne mel nejake switche, tak jsem mel Zvuk.prehraj() a podle typu objektu uz se provedlo nacteni, dekodovani a tak. Celkovy kod se tim o peknych par radku zkratil a zprehlednil.

(Samozrejme by to slo opsat makry, funkcemi jako prvky datove struktury, nebo to nabusit v assemblu, ale pro dany ucel ty objekty proste byly prehlednejsi, tak jsem je tam prsknul. Pro jiny ucel to muze byt zase zcela jinak.)

[Josef Kufner]

Ale stejně tak bys mohl mít funkci prehrej_zvuk(...), která by obsahovala ten jediný switch, který jsi schoval pomocí dědičnosti. Ono u dynamicky typovaných jazyků funguje polymorfismus i na úrovni funkcí, nikoliv jen objektů.

[Gilhad]

Jiste mohl a taky jsem to mohl udelat deseti jinymi zpusoby. Me se ale tenhle libil nejvic, protoze s temi zvuky (a nejen zvuky) se tam pracuje vic a je jednodussi pridat dalsi objekt na jedno misto a pripsat jen ty funkce, kde se to lisi, nez prolezat vsechny switche a davat to do nich.

Proste kdyz si muzu vybrat, jestli chci mi to programu rozhazeno spoustu switchu kazdy se spoustou polozek, nebo jestli chci jednu knihovnu s objekty, kde kazda metoda je na par radku, tak mi to druhe prijde prehlednejsi. Ono i pri ladeni, kdyz vidim, ze nejde zadny zvuk, tak je chyba nejspis v obecnem kodu, kdyz nejde jen jeden typ zvuku, tak je chyba v tom jednom objektu a je to jen par desitek radek.

Prijde mi zbytecne se objektum vyhybat, pokud je jazyk umoznuje a zprehledni to kod. Stejne tak mi prijde zbytecne rvat objekty vsude, kdyz to jde napsat prehledneji jinym zpusobem. Protoze ten program budu udrzovat asi jeste dlouho, tak ho radsi napisu tak, abych se v nem snadno orientoval a snadno ho mohl rozsirovat. Kdyz si pak za par let nekdo vzpomene, ze chce treba i podporu flacc, tak proste vezmu jeden z objektu, zkopnu ho a prepisu na flacc, misto abych lozil po celem programu, vsech knihovnach a okolnich programech a koukal, jestli tam nekde nemam v nejake funci switch se spoustou radek, ktery taky nesmim zapomenout upravit. Takhle jsou vsechny zmeny na jednom miste a zaroven se nemisi s ostatnim kodem (pribydou radky 50-120 v jednom souboru, misto aby v peti souborech pribylo po 14 radcich)

[Josef Kufner]

Tak ono ten switch nepotřebuješ. Klidně můžeš udělat něco jako:

$fn = "prehraj_".$typ;
if (function_exists($fn)) {
  $fn($zvuk, $delka, ...);
} else {
  error("Nepodporovaný typ zvuku.");
}

... a pak jen přidáváš funkce někam bokem. Dost podobně by se to dalo udělat i s třídama místo funkcí, ale to už je jen detail.

Podstatný je kvalitní návrh. Implementace je až druhořadá.

[Gilhad]

Porad mi prijde trochu prehlednejsi proste:

Zvuk.prehraj()

[R]

Alebo:

enum media_type { MEDIA_SOUND, ... };

struct media {
    enum media_type type;
    ...
}

void prehraj(struct media m) {
    switch(m.type) {
        case MEDIA_SOUND:
            ...
        case...
    }
}

[pht]

No, tak jsme zjistili, že dispatch (volání funkce dynamicky) se dá řešit polymorfizmem (děděním tříd), nebo if-kaskádou (resp. switch) nebo reflexí (to je takový to udělám si string a pak zkusím najít takovou funkci).

Taky jde předávat pointry na funkce a kdovíco ještě.

Každá z uvedených má své pro a proti a s tím, jestli je celý program napsán objektově, to nemá společného vůbec nic.

[pavlix]

Tak nějak, viz GObject :).

[Extak]

Z článku jsem vycítil orientaci autora spíše směrem k silně typovaným jazykům typu C#. Z pohledu PHP prográmatora, který už s PHP pracuje nějakých těch pár zim bych chtěl říct jenom pár věcí. Stejně jaky tady autor cupuje PHP, já bych po jednom měsíci používání např. C# pravděpodobně rozcupoval ten, protože bych se jej snažil používat podle zvyku. S programovacím jazykem je obvykle spjat i nějaký důvod proč vznikal a k čemu má být určen. Z mého pohledu PHP chybí spousta a spousta věcí, ale na to k čemu je určený funguje výborně. Na tvorbu malých a středních webových projektů neznám výkonnější nástroj. Ve firmě na kritické zakázky používáme javovské technologie jako GWT, které jsou podle mě vyspělejší než celý jazyk PHP, ale jejich vývoj je také podstatně dražší. I v PHP jsou napsány mnohé velice elegantní objektové programy, viz. v komentářích zmiňované Nette, Doctrine 2 a já bych přidal můj oblíbený Yii framework.

[zulu]

Zase nějaký "programátor"...