95 komentářů k článku PHP 5.4 přináší změny a nové jazykové konstrukce:

        1. Jakub VránaAutor příspěvku

          Re: safe mode

          Hlavní problém je ten, že skript nemůže pracovat se soubory v adresářích, které si sám vytvořil. To je potřeba třeba při kešování. Jde o to, že adresáře a soubory vytvořené webovým serverem mají jiného vlastníka než skript, který je vytváří.

          S takto vytvořenými soubory naopak může pracovat skript vytvořený aplikací úplně jiného uživatele (protože všechny soubory vytvořené webovým serverem mají stejného vlastníka, tak všechny takto vytvořené skripty mohou pracovat se všemi ostatními takto vytvořenými soubory, nehledě na původního vlastníka).

          Příklad: uživatel A si v aplikaci vytvoří soubor avatar.jpg. Uživatel B si v aplikaci vytvoří skript hack.php. Tento skript pak může pracovat se souborem avatar.jpg.

          1. Hugo

            Re: safe mode

            „Hlavní problém je ten, že skript nemůže pracovat se soubory v adresářích, které si sám vytvořil.“
            Preco by nemohol ?
            „To je potřeba třeba při kešování. Jde o to, že adresáře a soubory vytvořené webovým serverem mají jiného vlastníka než skript, který je vytváří.“ to je snad samozrejme, preco by mali mat rovnakeho ? A ked uz, preco to ohybat na strane web aplikacie ?

            „S takto vytvořenými soubory naopak může pracovat skript vytvořený aplikací úplně jiného uživatele (protože všechny soubory vytvořené webovým serverem mají stejného vlastníka, tak všechny takto vytvořené skripty mohou pracovat se všemi ostatními takto vytvořenými soubory, nehledě na původního vlastníka).
            Příklad: uživatel A si v aplikaci vytvoří soubor avatar.jpg. Uživatel B si v aplikaci vytvoří skript hack.php. Tento skript pak může pracovat se souborem avatar.jpg.“
            Pokial nema B korektne nastaveny open_basedir, co ine sa da ocakavat ?
            Popisane pripady vobec nevidim ako „nevyhody“ safemode.

            1. Jakub VránaAutor příspěvku

              Re: safe mode

              Safe mode kontroluje, jestli je vlastník skriptu totožný s vlastníkem souboru nebo adresáře, se kterým se tento skript pokouší pracovat. Takže když skript vytvoří adresář, tak tento adresář má jiného vlastníka, takže skript nemůže pracovat se soubory v něm uloženými.

              Stejného vlastníka by soubory měly mít proto, že to je systémový způsob oddělení více uživatelů na stejném serveru. Možné to je při spuštění PHP přes FastCGI.

              Hlavní účel safe mode se dá zkrátka mnohem snadněji a spolehlivěji dosáhnout pomocí open_basedir.

          2. Leoš

            Re: safe mode

            „Hlavní problém je ten, že skript nemůže pracovat se soubory v adresářích, které si sám vytvořil. To je potřeba třeba při kešování. Jde o to, že adresáře a soubory vytvořené webovým serverem mají jiného vlastníka než skript, který je vytváří.“

            Správně nastavené safe_mode_gid v kombinaci s atributem setgid na adresáři (což bohužel funguje jen na Linuxu) toto řeší.

  1. HosipLan

    Re: PHP 5.4 přináší změny a nové jazykové konstrukce

    Jakube, asi máš vyplý strict, že? :) Protože konstrukce

    $a = null; $a->a = 1; // nyní vyvolá varování (dříve potichu prošlo).

    mi vyvolá chybu:

    PHP Strict standards: Creating default object from empty value in Command line code on line 1

    A také bych se chtěl zeptat ohledně traitů… Některé zmatené zdroje uvádí, že v traitech by mělo jít definovat i vlastnosti, což jak vidno by asi opět muselo mít systém na řešení kolizí (já bych se bez něj obešel). Každopádně tato feature mi bude chybět :(

    1. Andrew

      Re: PHP 5.4 přináší změny a nové jazykové konstrukce

      Současná implementace traits umožňuje vlastnosti a bonus – kolize se neřeší :) Vypíše to něco jako:

      PHP Strict Standards: trait1 and trait2 define the same property ($property) in the composition of class. This might be incompatible, to improve maintainability consider using accessor methods in traits instead. Class was composed in … on line …

      1. HosipLan

        Re: PHP 5.4 přináší změny a nové jazykové konstrukce

        Koukali jsme do testů v SVN s kolegou a fakt to tam je! Otvírám flašku :)

    2. Jakub VránaAutor příspěvku

      Re: PHP 5.4 přináší změny a nové jazykové konstrukce

      U tohoto bodu jsem vyšel z textu v news.txt: “Changed silent casting of null/ ''/ false into an Object when adding a property into a warning.” Ověřil jsem si, že v nové verzi se skutečně vyvolá varování, ale už jsem si neověřil chování ve staré verzi. Omlouvám se za nepřesnost.

      Sám tento obrat nepoužívám.

  2. kukulich

    Re: PHP 5.4 přináší změny a nové jazykové konstrukce

    1) Odstranění magic_quotes je ještě v todo k diskuzi, viz https://wiki.php.net/todo/php54
    2) V ReflectionClass přibyly ještě čtyři metody související s traits, ale ještě nejsou v dokumentaci.
    3) V příští alphě bude ještě určitě jedna velká novinka a to build-in webserver, viz https://wiki.php.net/rfc/builtinwebserver

    A jinak věřím, že s ApiGenem budeme první dokumentační nástroj, který bude traits podporovat. Už jsme na tom začali dělat :)

    1. Jakub VránaAutor příspěvku

      Re: PHP 5.4 přináší změny a nové jazykové konstrukce

      2) Díky za tip, dokumentaci jsem doplnil.

      To s tím prvním frameworkem a prvním dokumentačním nástrojem byl jen takový hec :-). Já moc dobře tuším, jak to dopadne. Nette už taky začalo.

      1. adrive

        Re: PHP 5.4 přináší změny a nové jazykové konstrukce

        Tie také hecy mi prídu ako keď sa bavia dvaja, kto má väčší… Keď pozerám na DGXov gist, tak podľa komentáru pod ním (2 days ago) by som povedal, že Benjamin Eberlei hodil prvý pokus dva týždne skorej…

  3. Proki

    $this v closure

    Mě osobně asi nejvíce těší automatická přítomnost proměnné $this v closure (navíc konečně bude možnost se přes $this dostat i k private a protected atributům a metodám dané třídy).

  4. Jahudka

    Argh!

    Uplne mi vre krev:

    • Bez náhrady zdá se zmizela i užitečná direktiva safe_mode_exec_dir – Oduvodneni, proc je tato direktiva uzitecna mi nejak nesedi. PHP by do takovych veci sahat snad nemelo, popripade, kdyz nekdo potrebuje nejakou obdobnou specialitu, musi si poridit vlastni server. Nevidim na zruseni tohoto a ostatnich safe_mode paskvilu nic spatneho.
    • $a = null; $a->a = 1; nyní vyvolá varování (dříve potichu prošlo) – Projde, pokud je programator prase – s E_STRICT dostanu „Strict standards violation“. Tedy opet neco navic pro deti, ktere se dostaly k PHP a mysli si, ze umi programovat.
    • např. kód <?php echo "?><"; ?> – Boha jeho, proc by toto nekdo psal? Proc se tu utapime v takovych nepravdepodobnych prikladech?
    • new C; – Jak ja nemam rad vytvareni instance bez zavorek. Kdyby autorem nebyl Jakub Vrana, na miste bych prohlasil, ze jde o a) preklep, b) neznalost / ignoranci kodera

    Co se pak tyce dalsich direktiv… nekoukal jsem do podrobnosti, ale ponekud me zarazi: f()[0]. Skutecne mohu vratit jen prvni prvek pole? Nebo jakykoliv pomoci f()[$n]. Pokud je to pevne spjate na prvni index, je toto „zlepseni“ v podstate k nicemu.

    Taktez jsem zaskocen trait. Obdobne konstrukce mohou byt uzitecne, ve vetsim projektu si je ale nedovedu predstavit. Zavadeni magie pouzite v nespravnych rukou – to nikdy nedelalo dobrotu. Navic mam pocit, ze to je spise takova berlicka pro ty, kteri si nevystaci/neumi si poradit se znamymi navrhovymi vzory a musi lepit vse dohromady podobnym zpusobem

    1. jlx

      Re: Argh!

      Ad f()[0]:
      Tam jde o tzv. array dereferencing, tj. pokud funkce vraci pole, tak muzu vracenou hodnotu rovnou pouzit ve vyrazu, cili napriklad pristupovat k prvkum pole. Predtim bylo nutne vracene pole nejdriv ulozit do promenne a teprve potom slo pristupovat k jeho prvkum.

      1. blizz

        Re: Argh!

        tiež som nechápal prečo to v PHP doteraz nefungovalo, veď v každom normálnom jazyku to funguje.

        a zápis (new Trieda)->metoda() by mohol tiež fungovať neviem prečo to musím rozpisovať na 10 riadkov keď chcem volať len jednu metódu.

        PHP je jednoducho nekonzistentný a ukecaný jazyk.

        btw ešte by mohli zrušiť nutnosť písať $this pred každý member a taktiež nahradiť šípku nejakým iným znakom hlavne nech je to len jeden znak. a tiež zaviesť properties a implicitné properties namiesto get a set metód.

        1. Oldis

          Re: Argh!

          Tak zrovna (new Trieda)->metoda() tohle mi prijde zhola zbytecne. pokud je toto potreba, patrne jde o chybu navrhu. abych vytvarel tridu kvuli tomu ze z ni budu volat jednu metodu, nevim nevim.

          1. blizz

            Re: Argh!

            neni to zlý návrh v iných jazykoch sa to bežne používa.

            napr.:

            using (var stream = File.Open(@“C:su­bor.dat“, FileMode.OpenRead))
            {
            var text = new StreamReader(stre­am).ReadLine(); //čítam textový reťazec
            stream.Position = 56;
            var num = new BinaryReader(stre­am).ReadInt64(); //čítam číslo ktoré je uložené binárne
            }

            1. František Kučera

              Re: Argh!

              Že se to v nějakém (pa)jazyce běžně používá, ještě neznamená, že to není chyba návrhu :-)

              Ono vytvářet objekt, aby zavolal jednu jeho metodu a vzápětí ho zahodil, nemá s OOP moc společného. Je to vlastně procedurální programování a seděla by tam více procedura nebo funkce – případně když je to objektový jazyk, tak statická metoda v knihovní třídě.

              1. blizz

                Re: Argh!

                „Ono vytvářet objekt, aby zavolal jednu jeho metodu a vzápětí ho zahodil, nemá s OOP moc společného.

                Vašej logike nerozumiem. Keď potrebujem na objekte zavolať len jednu metódu tak na ňom predsa nebudem volať viac metód. Ako súvisí počet zavolaných metód s programovacou paradigmou? Vytvoril som objekt? Vytvoril. Poslal som mu správu? Poslal. Pretože som ho už ďalej nepotreboval tak som ho zahodil. Jednoduchšie sa to už nedá vysvetliť.

              2. mrj

                Re: Argh!

                To, ze na objektu volam jen jednu metodu snad neznamena, ze nemuze mit tech metod vic… Muze jit treba o settery ktery ale nebude potreba volat protoze staci default hodnoty. Nevidim duvod proc by to jit nemelo i kdyz jeden radek navic nikoho nezabije…

              3. wdolek

                Re: Argh!

                a kdyz si kod zaneseme statickymi metodami, to se nam bude pekne testovat!… nevidim na uvadenem prikladu nic spatneho, at uz jde o jakykoliv jazyk.

                1. František Kučera

                  Re: Argh!

                  Statické metody se špatně testují? To je mi ale novina.

                  Naopak, je to na testování* to nejjednodušší – je to de facto funkce, není na ničem jiném závislá (tzn. není potřeba kolem ní simulovat nějaké prostředí) a má jednoduchý vstup a výstup, který se krásně testuje.

                  Co se týče těch konstrukcí typu:

                  Třída1 proměnná1 = new Třída2().něja­káMetoda();

                  Taky jsem to takhle už párkrát někde napsal, ale je potřeba to brát jako výjimečný případ – rozhodně to není něco normálního, běžného. Pokud se tyhle konstrukce objevují v kódu často, skutečně to nasvědčuje chybě návrhu. 1) Buď na straně autora Třídy2, který zbytečně nutí ostatní vytvářet instance. Je to asi jako kdybychom museli vytvářet instanci java.lang.Math, když chceme jen spočítat sinus nějakého úhlu.
                  2) Nebo je to chyba toho, kdo Třídu2 takhle používá – protože zbytečně vytváří velké množství instancí a pak je zahazuje, místo aby jeden objekt použil vícekrát.

                  A pak ještě občas člověk naráží na začátečníci, kteří říkají, jaký je to OOP opruz, že přece v céčku by jednoduše zavolali jednu funkci a tady se musí navíc obtěžovat s vytvářením nějakých instancí.

                  P.S. Nevidím důvod, proč by tahle možnost v PHP neměla být – ale chtěl jsem tím říct, že by se měla používat s rozmyslem nebo pokud možno vůbec.

                  *) předpokládám, že mluvíme o jednotkovém, protože to tady lidi berou jako totéž a o existenci jiných druhů testů moc neví.

                  1. Oldis

                    Re: Argh!

                    Ano, presne tak sem to myslel, bud to potrebuju jako rozhrani, pak nemam duvod z toho udelat singleton a v kodu dal pouzivat dalsi metody, nebo spise procedury nezavisle na sobe a nebo to ma skoncit jako staticka metoda v knihovne zprostredkujici rohrani singletonu, nebo co ja vim, ale rozhodne mi neprijde jako dobrej napad vytvaret instanci, zavolat z ni jednu metodu a rovnou ji zahodit, dejme tomu ze parkrat v kodu bych to prekousnul, ale pokud se to v kodu objevuje prilis casto nebo bezne, zacal bych nadavat a kodera bych to nechal predelat.

                  2. blizz

                    Re: Argh!

                    „Taky jsem to takhle už párkrát někde napsal, ale je potřeba to brát jako výjimečný případ – rozhodně to není něco normálního“

                    Je to uplne normalne:

                    var a = „Abcd“.ToLower()­.Substring(2);

                    napr. v tomto riadku som 3x vytvoril objekt typu string a 2x som ho zahodil.

                    alebo trebars v cisto objektovych jazykoch ako ruby, kde aj cisla su objekty:

                    a = 1 + 1

                    som vytvoril 3 objekty, pricom 2 som hned zahodil. podla vasej logiky by som to mal asi rozpisat na 10 riadkov…

                    1. Oldis

                      Re: Argh!

                      „var a = „Abcd“.ToLower()­.Substring(2);
                      napr. v tomto riadku som 3x vytvoril objekt typu string a 2x som ho zahodil.“
                      zalezi jak jsou implementovany fce sco se volaji, pokud vraci puvodni instanci, tak jste vytvoril jen jednu a nakonec ste ji vrazil do promenne a. pokud si fce zklonuji this a pak vraci klon tak se vytvorili tri instance.

                      „a = 1 + 1

                      som vytvoril 3 objekty, pricom 2 som hned zahodil. podla vasej logiky by som to mal asi rozpisat na 10 riadkov…“
                      tohle necham bez komentare, pripady o kterych se zde bavime jsou z jineho soudku. nikomu se napriklad nebrani udelat var a = „abc“.toUpper() + „def“; i kdyz to zjevne muze byt kravina, protoze je to bezpredmetnej priklad.

                      1. blizz

                        Re: Argh!

                        Typ string je vo väčšine objektových jazykov implementovaný ako immutable objekt (je nemenný) a teda pri každej operácii sa vracia nový reťazec.

    2. Jakub VránaAutor příspěvku

      Re: Argh!

      1. Direktiva safe_mode_exec_dir je užitečná především na sdílených hostinzích – tedy přesně v případech určených pro klienty, kteří si vlastní server pořizovat nechtějí. Někdy by v takovém případě mohlo být lepší použít FastCGI, ale taky zdaleka ne vždy (protože každý uživatel musí mít svou vlastní sadu procesů, takže když mám třeba 100 uživatelů a pro každého chci 20 procesů, už jsme na 2000 procesech, což je mnohem víc než v případě modulu, kdy bych si vystačil třeba se stovkou, které by obsluhovaly všechny uživatele). Nechat si každého pořídit svůj vlastní server je „nejsprávnější“, ale rozhodně ne ekonomické (a třeba taky ekologické).

      Výsledkem bude, že buď na sdílených hostinzích zakážou programy příkazového řádku spouštět úplně (což omezí funkčnost) nebo je naopak úplně povolí (což zhorší bezpečnost). Je naivní si myslet, že všichni sdílené hostingy zruší (nebo alespoň přejdou na FastCGI).

      2. K tomuto bodu už jsem se v diskusi vyjadřoval.

      3. Tady nejde o nepravděpodobný příklad – jde o to ukázat, že na XML validitu se u PHP skriptů nedá spoléhat. A když se na něco nedá spoléhat, tak je lepší s tím vůbec nepočítat, než se potom divit. Kromě řetězců může stejný problém nastat i u komentářů.

      4. A jak já nemám rád diskusní trolly… O neznalost nebo ignoranci čeho jde?

      5. Dá se odkázat na jakýkoliv prvek, jak je ostatně patrné i z příkladu v článku. Nenapadlo mě, že někdo ukázku použití pochopí tak, že se dá odkázat jen na první prvek pole. A abych předešel dalšímu dotazu – obrat se dá použít i u funkcí, které se nejmenují f.

      1. Jahudka

        Re: Argh!

        1. Ano, sdilene hostingy nebudou mit moznost volani prikazu z PHP skriptu. To mi prijde logicke. Pokud nekdo tuto moznost potrebuje, asi nedela na svem blogisku, takze si urcite rad zaplati alespon virtualni strojek.

        3. Ano, XML validita neni a nikdy nebyla. Proto jsem byl timto bodem prekvapen, protoze mi to prijde jako rikat, ze voda neni horlava (nebo neco podobneho).

        4. Ano, asi jsem se nemel vyjadrovat ke konvencim nekoho jineho ;) byl jsem ale uz tak dost dopaleny…

        Duvod, proc nemam rad instanciaci bez zavorek (a opovrhuji takovym zpusobem psani kodu) je ten, ze „volam konstruktor“ – tedy metodu. Co „hur“, kdyz do konstruktoru predavam parametr, musim psat new Foo($bar);, kde zavorky jsou. Pro me je pak nepochopitelne, proc nekdo pri absenci parametru proste jen tak zrusi i zavorky. Pro me je to celek, a vetsinou tento styl pozoruji u studentu informatiky, kteri poradne nevedi, co delaji (nechapou rozdil mezi promennou, volanim funkce, identifikatorem tridy apod.)

        5. Z diskuse a prvniho vygoogleneho linku na nejakem foru mi bohuzel prislo, ze se to skutecne vztahuje jen na [0], tak se omlouvam, ze jsem si to chtel ujasnit (bez hlubsi reserse primo u zdroje). Ale popravde, u autoru PHP by me skutecne prilis neprekvapilo, kdyby to bylo pouze pro prvni prvek.

        1. Jakub VránaAutor příspěvku

          Re: Argh!

          1. V praxi se to asi nejčastěji používá pro volání ImageMagicku, který je šetrnější než GD2 dostupné v PHP a hosteři tvrdí, že stabilnější než extenze ImageMagicku pro PHP. Takže hlavním důvodem je zase snižování nákladů.

          3. Hlavní argument proti <? je právě XML validita. Chtěl jsem ukázat, že ta není v obecném případě zaručena ani při použití <?php. Navíc váš původní komentář byl přesně v opačném duchu – odkazoval se na nepravděpodobný příklad, kterým se není potřeba zabývat.

          4. Používat obraty jako „neznalost“ a „ignorance“ je poněkud neuvážené, pokud jde pouze o vlastní konvenci. Já rád přiznávám pravý stav věcí, takže píšu include "a" – nikoliv include("a"), píšu exit – nikoliv exit() a píšu new A – nikoliv new A(). Podle vaší argumentace byste přesně vy byl ten případ, který nechápe, co se děje. Protože new A() není zavolání konstruktoru – je to vytvoření objektu (při čemž se volá konstruktor). A vytvoření objektu vyjadřuje operátor new.

          5. Úplně by stačilo přečíst si článek, na který reagujete.

          1. Jahudka

            Re: Argh!

            Dovolim si rypnuti: ano, kdybych sel do FB, take bych mel ve vsem pravdu (narazim predevsim na bod 4.) ;)

            Preji pekny den a co nejmene magie v NotORM!

            1. Jakub VránaAutor příspěvku

              Re: Argh!

              4. V tom mezi námi spatřuji největší rozdíl. Já používám nějaký způsob zápisu, který mám podložený racionálními rozhodnutími. Ale netvrdím, že je jediný správný a neopovážil bych se někomu s jiným způsobem zápisu kázat něco o neznalosti nebo ignoranství. Navíc v případě, kdy argumenty jsou značně chatrné (záměna vytváření objektu s voláním konstruktoru – tím jste se pasoval přesně do role těch studentů, kteří nevědí, co dělají).

              1. Jahudka

                Re: Argh!

                Jiste :) uz jsem uznal, ze to bylo nemistne a v afektu. Za to se omlouvam. Na druhou stranu, kdyz takto zapsany kod vidate prave u tech, tkeri nevi co to znamena, pak to svadi k takovym uvaham. Znam snad dva lidi, kteri pouzivaji takovou konvenci – druhym je dgx. Cely svet jede podle nejake konvence, u nas v cechach je ostruvek jinakosti. Nemohu rict, ze je to spatne nebo dobre.

                Jak co kdo pise, to je na osobnim uvazeni, snad jako jaka barva se komu libi. Takze znovu :) omlouvam se za muj afektovany prispevek.

                Co se tyce „zameny“ – vzdy jsem mel za to, ze kdyz neco napisu do uvozovek („volam konstruktor“), zmeni to nepatrne vyznam (dle kontextu). V tomto ohledu pak byla Vase reakce obdobne prehnana ;) …
                Nevim, jestli jsem vyrustal v nejakem specialnim prostredi, mozna jsem „vyrustal“ na zlem C, Jave, C#, kde bych si nedovolil neco takoveho napsat… (stale mi tam ale vadi nekonzistentnost ( new Foo; vs new Foo($bar);)).

                1. Nox

                  Re: Argh!

                  Ach jo, trolling… „neznalost“ je když programátor *chápe* že „new“ slouží k vytvoření instance?

                  Stejnou konvenci používá třeba Doctrine tým, asi by to chtělo větší rozhled https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/EntityManager.php#L176

                  Myslím že jste předchozí reakci „záměna“ nepochopil a navíc si ještě protiřečíte: jak může být nekonzistence mezi významově odlišnými zápisy – když už tedy najedu na vaši puntičkářskou notu…

                  Navíc zápis new ClassName; je absolutně čitelný a jasný …

                  Píšete že jste to přehnal a pak napíšete snad ještě více přehnanou reakci ;) tak jsem to taky trochu přehnal abych náhodou nezůstal pozadu

                  1. Jahudka

                    Re: Argh!

                    Pokud by mi slo o citelnost, ve smyslu, aby se kod nejvice podobal lidske reci, budu asi programovat ve Smalltaku a ne v PHP.

                    Pokud jde o konvence, mam rad nejake jasne pravidla – a vzhledem k me minulosti je zjevne, co preferuji. Rozdeluji „jmeno tridy“ na pripad, kdy tridu deklaruji a kdy ji instancuji. Obdobne je to s funkcemi… Ale asi jsem tedy jediny na cele planete…

                    Zatrolleny flame!

                      1. Jakub VránaAutor příspěvku

                        Re: Argh!

                        Volání konstruktoru nezáleží na tom, jestli tam závorky jsou nebo nejsou, ale na tom, jestli je konstruktor definovaný.

                        1. wdolek

                          Re: Argh!

                          ale stale je „konstruktor“ pevne spjat s vytvarenim instance, at uz ho programator sam vyrobil nebo ne. zavorky jsou preci fain :)

                    1. Nox

                      Re: Argh!

                      Coding standard je snad vytvářený z důvodu čitelnosti… jinak by byl jen proto aby byl, aby to bylo „kůl“ (u vás by se to asi vyjádřilo jinak ale význam by byl stejný)

                      Dále prostě holt není jen jeden a ten váš není „One True Coding Standard“, svět není černobílý, smiřte se s tím

                      Pokud je problém poznat že „new ClassName;“ není deklarace třídy ale instancování … pak už fakt tuhle debatu vzdávám

                      1. wdolek

                        Re: Argh!

                        ja bych to spise videl tak, ze by bylo dobre pouzivat v c-like jazyku to, co se v nem bezne vida a nechytat se nejakych PHP vymozenosti. samozrejme, kdyz nekdo prejde z Javy na PHP nebo opacne, musi si davat pozor co pise – urcite to ale cloveku pomuze, kdyz neni zvykly na podobne „vychytavky“ jednoho z jazyku.

    3. anonym

      Re: Argh!

      trait také nechápu. Když autoři PHP touží po vícenásobné dědičnosti, tak ať ji transparentně zavedou. Tohle to mi smrdí paskvilem: nepřehlednější než vícenásobná dědičnost a evidentně autoři nesdílí názor na přínos jednoduché dědičnosti v kombinaci s rozhraními.

      1. Jakub VránaAutor příspěvku

        Re: Argh!

        Autoři po vícenásobné dědičnosti netouží. Pokud chápeme dědičnost jako vyjádření vztahu „je“, tak jednonásobná dědičnost dostačuje – něco nemůže být zároveň psem a kočkou. Rozhraní vyjadřují vtah „umí“ – objekt může umět totéž co pes a kočka. A trait vyjadřuje vztah „dělá“ – objekt může dělat totéž co pes i totéž co kočka.

        Za hezkou považuji ukázku použití v Nette – třídám mohu vnuknout stejnou funkčnost, aniž bych je musel z něčeho dědit (což často ani nejde).

        1. anonym

          Re: Argh!

          Hezky vysvětleno, děkuji.

          Ta Nette ukázka to používá k rozšíření funkčnosti nějaké třídy o jinou funkčnost (metody). Téhož lze ale dosáhnout zapouzdřením „Trait“ objektu do rozšiřovaného objektu. Pořád nechápu přidanou hodnotu proti klasickému objektovému přístupu. Snad jen v definici ještě na úrovni tříd, ale i to lze díky typování zajistit čistě objektově.

          Nebo to má něco společného s aspektově orientovaným programováním? Na to mi tam chybí přípojné body.

          1. Jakub VránaAutor příspěvku

            Re: Argh!

            Termín „zapouzdření“ je použit poněkud nešťastně, v obvyklé terminologii se používá pro něco jiného. Samozřejmě jde chování traitů dosáhnout i bez nich, ale je to poněkud krkolomné. To je to „potupné zopakování“, o kterém píšu v článku.

            1. anonym

              Re: Argh!

              Pravda, „zapouzdření“ má jiný význam.

              OK, nyní chápu, v čem vidíte přínos.
              Já bych to řešil spíše pomocí rozhraní, dokonce tipuji na to bude nějaký návrhový vzor.


              interface umiFunkcionalitu {
              public getTrait();
              }

              class Trait {
              public function volanaMetoda();
              }

              class RozsirovanyObjekt extends Cokoliv implements umiFunkcionalitu{
              private $trait;
              public function getTrait(){
              if(!($trait instanceof Trait)) throw new Exception();
              return $this->trait;
              }
              public function setTrait(Trait $trait){
              $this->trait=$trait;
              }
              }

              //inicializace
              $trait=new Trait();
              $o = new RozsirovanyOb­jekt();
              $o->setTrait($trait);

              //pouziti
              $o->getTrait()->volanaMetoda();

              Za případné syntaktické chyby se omlouvám.

              1. Jakub VránaAutor příspěvku

                Re: Argh!

                Volání $o->getTrait()->volanaMetoda() je taky krkolomné (v tomto případě ne pouze pro třídu, ale pro veškerý kód, který ji používá). Navíc tím nelze implementovat rozhraní (takže by se např. muselo volat foreach ($o->getTrait() as $val) místo elegantního foreach ($o as $val)). Další nevýhodou je, že $o->getTrait() nevidí neveřejné vlastnosti a metody rozšiřované třídy.

                1. anonym

                  Re: Argh!

                  $o->getTrait()->volanaMetoda() je pouze příklad. Pokud nějaký kód bude s $trait pracovat, pochopitelně si ho nejdříve načte, a pak s ním pracuje. Hlavní výhodu spatřuji v absenci magie a transparentnosti.

                  Druhý argument mi také nepřipadá jako závažný a to ze stejných důvodů.

                  K třetímu nevidím žádný důvod, pokud bylo záměrem jen získat nějakou existující instanci třídy Traid.

                  Ukončeme to. Traits mohou být šikovné, ale za cenu magie v kódu. V PHP prostě jsou, tak se s tím musím smířit.

                  1. Jakub VránaAutor příspěvku

                    Re: Argh!

                    O žádnou magii nejde. Traits budou běžnou jazykovou konstrukcí a programátor by se je měl ve vlastním zájmu naučit používat (nebo alespoň číst). Podle stejné logiky by se dalo říct, že dědičnost je magie, protože voláme metodu, která není ve třídě definovaná (protože je v jejím předkovi).

                    1. wdolek

                      Re: Argh!

                      dovolil bych si oponovat. ano, mozna nejde primo o „magii“, u dedicnosti ale clovek okamzite vidi strom dedicnosti a je schopen si dohledat, kde se funkce vzala.

                      u traits to vidim tak, ze clovek nejdrive zkontroluje strom dedicnosti. chvilku se bude drbat na hlave a vykrikovat „wtf“. pote se zacne zaobirat kodem modelu – tam nic nenajde, tak zacne louskat nejaky prezentacni kod a az tam najde, ze nekdo do objektu A nacpal funkce foo() pomoci trait.

                      co bude roztomile, kdyz programator traits priradi rovnou do vice trid (jejich ucel). pri absenci dokumentace pak bude druhy programator ztracen, nehlede na jeho uroven znalosti traits. (tedy, muj nazor – v praxi jsem se s tim jeste nesetkal)

                      ze se to clovek nauci pouzivat / cist – neprijde mi to dostatecne KISS.

                      a odbocil bych: ono je to jako s __call metodami v Nette, mozna i v NotORM. to aby se clovek rozkrajel, nez se dopatra, co se kde deje a proc. jeste k tomu pridame traits a meme pekne obfuscated kod :)

          2. Vrtak-CZ

            Re: Argh!

            Využití traitů najdeš tipicky pokud rozšiřuješ nějakou třídu z knihovny třetí strany (což není nic neobviklého).

            Jako příklad uvedu Repository z Doctrine 2 ORM do které chci přidat funkcionalitu NetteObject.

            1. anonym

              Re: Argh!

              Právě to mi připadá jako důvod, proč to neumožnit vůbec používat. To co chcete vy přeci řeší transparentně nějaká obalovací třída:

              class Obal extends Object {

              private $repository;

              public function __construct(Re­pository $repository){
              $this->repostiory=$re­pository;
              }

              public function getRepository(){
              return $this->repository();
              }
              }

              Při tomto řešení nehrozí žádná kolize jmen a dodrží-li autor Repository své veřejné rozhraní, jeho aktualizace nikdy neohrozí můj kód.

              Pokud dobře chápu traits, tak vy podědíte a rozšíříte cizí třídu, její autor pak v nové verzi pojmenuje svou metodu stejně jako vy a vám po aktualizaci knihoven aplikace přestane fungovat.

              1. Jakub VránaAutor příspěvku

                Re: Argh!

                Totéž se dá říct o rozhraních. Jakmile implementuji rozhraní, tak se vystavuji riziku možné budoucí nefunkčnosti. Pokud implementuji více rozhraní, tak se vystavuji riziku vzniku kolizí. V praxi to ale velký problém nepředstavuje.

    1. HosipLan

      Re: Bude finally

      Nejspíš by bylo dobré, sepsat na to RFC pro PHP, pokud si myslíš, že by se to hodilo :)

        1. HosipLan

          Re: Bude finally

          To je smutné, jsou vývojáři PHP vždycky takový ignoranti? S takovou se mě brzo zmocní paranoia a budu přecházet na node.js nebo Ruby…

          1. kukulich

            Re: Bude finally

            To není ignorance. Ale prostě se tehdy rozhodli, že se to do PHP nehodí a není to potřeba. Možná že od té doby už názor změnili nebo už jsou tam jiní vývojáři, ale musel by se objevit někdo, kdo napíše RFC, proč to chce, a ideálně i udělá patch. Ale napsat RFC by možná stačilo. Aspoň by se o tom začalo znovu mluvit.

  5. Hufo

    Sejfmod

    Priznam sa, ze tiez nerozumiem, ked niekto privita vyhodenie safe_mode a vadi mu vypustenie safe_mode_exec_dir , ktore je na tom priamo zavisle a suvisi s tym :)
    Som skor zastanca zachovania safe modu (hostingove dovody), s tym, ze kto chce, ho nemusi pouzivat.
    Ale viete mi niekto vysvetlit, preco vobec existuju bezne aplikacie (aj tie „znackove“ CMS), ktore nemaju radi safemode=on, ci dokonca ho vyzaduju vypnuty ? Co to je za programatorov, ktory maju problem sa s vlastnou web aplikaciou vojst do vlastneho adresaroveho stromu, nekorektne pouzivaju tmp adresare, ci nedokazu spravne uploadovat data ?
    Predpokladam, ze koderom PHP vypustenie safe modu zjednodusi kod, co beriem, ale inak tie dovody typu – ma to mat na starosti OS – povazujem za cisto alibisticke.

    1. Jakub VránaAutor příspěvku

      Re: Sejfmod

      Direktiva safe_mode_exec_dir se safe mode vlastně vůbec nesouvisí. Klidně by mohla být na nastavení safe_mode nezávislá a mohla by se jmenovat třeba allowed_exec_dir. Možnost omezit spouštěné programy se může hodit, protože pokud je povolíme všechny, tak se ztrácí smysl i open_basedir (který zůstává, protože hlavní smysl safe mode zastává mnohem lépe).

      Nefunkčnost a nebezpečnost safe_mode jsem v této diskusi už popsal. Spíš to na mě působí, jako byste si to spletl právě s open_basedir.

      1. Hugo

        Re: Sejfmod

        Ano mohla by byt, ale v sucasnosti je sucastou safe mode.
        Samozrejme, ze som za zachovanie base_opendir.

        Nie nesplietol, no pouzivat safe mode bez open_basedir je nezmysel, tieto dva mechanizmy sa vhodne doplnaju.

  6. maertien

    Register_globals

    Tak mne ceka prepisovani ;-) I kdyz jsem to nikdy nepouzival, tak ve zdrojacich od jinych lidi, o ktere se nyni staram, je to hojne vyuzivana vec.

    1. Jakub VránaAutor příspěvku

      Re: Register_globals

      Nejjednodušší záplata je extract($_REQU­EST), ale obvykle je skutečně lepší přepis.

  7. Nox

    spokojenost

    Aby tu nebylo jen brblání – mě se změny, nové vlastnosti, líbí a výkonostní zlepšení vypadá velmi hezky.
    Na minor verzi pěkné, asi ne dokonalé ale slušné

  8. adrive

    file upload progress

    Čo sa týka progresu uploadu, tak tam mi chýba ešte informácia v tom poli, koľko má daný súbor veľkosť. Je tam len content length pre všetky súbory, ale potom pre jednotlivé to už nie je…

    1. LM_

      Re: file upload progress

      Velikost souboru nelze zjistit, u multipart/form-data se u jednotlivých částí délka neuvádí.

  9. Miloslav Hůla

    Traits a zapouzdření

    Díky za pěkné shrnutí změn.

    Mám dotaz k traits. Mají metody definované v traitu přístup k private a protected metodám třídy, která trait používá?

    1. Jakub VránaAutor příspěvku

      Re: Traits a zapouzdření

      Ano:

      trait T {
          function f() {
              return $this->x;
          }
      }
      
      class C {
          use T;
          private $x = 3;
      }
      
      $c = new C;
      echo $c->f(); // vypíše 3 
  10. Oldis

    Traits je chaba nahrada vicenasobne dedicnosti

    spise to zavadi do kodu zmatek, proc se lide kolem vyvoje php neinspirovali u c++ ? ;)

    1. wdolek

      Re: Traits je chaba nahrada vicenasobne dedicnosti

      ale urcite se inspirovali… a pak jeste asi u dalsich 10ti jazyku :D

  11. xxxObiWan

    Traits, k čemu vlastně?

    Dobrý den, nějak mi to pořád nedocvaklo… Jaký je rozdíl mezi

    > trait A {}
    >
    > class B {
    > use A;
    > }

    a

    > abstract class A {}
    >
    > class B extends A {
    > }

    ??

    1. tiso

      Re: Traits, k čemu vlastně?

      Máš príliš jednoduchý príklad. Ako by si implementoval toto:
      - trieda A s metódou MA
      - trieda B s metódou MB
      - trieda C s metódami MA i MB
      bez opakovania kódu? Toto skrátka nepodedíš.

      1. lopata

        Re: Traits, k čemu vlastně?

        Normální kompozicí, co bych dědil. Třídy A a B dostanou C a zavolají si MA nebo MB a nebo opačně C dostane A a B a zavolá MA nebo MB, tohle se přece dělá už léta.

        Traity nejsou nic jiného než takový automatizovaný copy paste, možná i v compile time a není to nic, bez čeho by se nešlo pohodlně obejít.

        Spíš souhlasím s tím, že PHPčkaři jsou většinou zvyklí rychle prasit než přemýšlet a tak budou prasit i návrh tříd s traity.

        1. tiso

          Re: Traits, k čemu vlastně?

          Príspevok, na ktorý som reagoval, bol o rozdieloch medzi trait a dedením. Na tom pôvodnom príklade totiž nebolo ten rozdiel vidno, preto som uviedol iný.
          Kompozícia je jedno z riešení, dá sa použiť aj v pôvodnom príklade.

  12. Jakub VránaAutor příspěvku

    Magic quotes nejspíš zmizí

    Stas Malyshev (Release Manager PHP 5.4) mi potvrdil, že magic quotes před vydáním beta verze nejspíš zmizí. S nimi související funkce ale zůstanou (vysvětluji si to tak, že např. get_magic_quo­tes_gpc zůstane, ale bude vracet vždy false).

    To považuji za ideální stav.

  13. jos

    traits - syntaxe

    traity super, jen ta syntaxe se mi zdá divná

    proč je to zrovna

    <?php
    class c
    extends e
    implements i
    {
      use t;
    }

    a ne

    <?php
    class c
    extends e
    uses t
    implements i
    {
    }

    ?

  14. expert

    PHP versus Python

    PHP má oproti Pythonu zásadní nevýhodu. Nevytváří objektovou abstrakci nad importovanými soubory jako pythoní balíčky a moduly.

    Také podpora first-class functions je, řekl bych, nestandartní. O nepodpoře callable objektů nemluvě. Nic jako __call__ v PHP není. Metaclasses-nic. Operátor overloading chybí.

    Stejně mě také udivuje metoda die(). To jako když program umře uprostřed, dostanu poloviční výstup? Kde to jsme?

    PHP vychovává programátory-amatéry, kteří mastí dohromady PHP, HTML, SQL a bůhvíco ještě. Programovat v PHP něco jiného než pro web (GUI, multiprocessing, systémové programování) je jako nošení dříví do lesa.

    Zato Python, to je jazyk pro bohy.

    1. Jakub VránaAutor příspěvku

      Re: PHP versus Python

      Než začnete něco srovnávat, musíte to nejprve znát.

      • Metoda __invoke
      • Rozšíření Operator
      • Funkce sys.exit

        To, že přetěžování operátorů není běžnou součástí jazyka, není nějaké opomenutí, ale záměr návrhu jazyka.

        Ukončení programu je zcela běžný obrat. Nepodařilo se připojit k databázi? Zobrazím chybovou stránku a skončím. Podařilo se uložit data v metodě POST? Přesměruji uživatele a skončím. Přišel neplatný parametr na příkazové řádce? Zobrazím nápovědu a skončím.

        PHP, HTML, SQL a bůhvíco ještě se dá míchat v PHP stejně jako v jakémkoliv jiném jazyce. Stejně tak se to ale v PHP dá snadno oddělit.

      1. jos

        Re: PHP versus Python

        mno rozšíření Operator se svojí verzí 0.3 beta z roku 2006 bych asi nezmiňoval, škoda že to ta ženská nedotáhla do konce – teda radši bych aby dotáhla do konce Runkit

        1. Jakub VránaAutor příspěvku

          Re: PHP versus Python

          Pro tuto diskuse je důležité, že to jde (nechybí to, jak jste uvedl). Já jsem to třeba elegantně využil. Do produkčního kódu bych to ale nepustil – jednak samozřejmě proto, že je to stará beta, ale hlavně proto, že to kód zatemňuje. To se přesně slučuje se záměrem návrhu jazyka.

  15. kukulich

    Další změny

    Tak a je odhlasováno, že by se ještě měly objevit tyto změny:

    1) Add E_STRICT to E_ALL
    2) Add option to disable POST data processing
    3) Support binary notation (0b1010101), viz https://wiki.php.net/rfc/binnotation4ints
    4) Remove magic quotes
    5) Array short syntax, viz https://wiki.php.net/rfc/shortsyntaxforarrays
    6) Callable typecheck in arguments, viz https://wiki.php.net/rfc/callable
    7) Change rebinding behavior of closures, viz https://wiki.php.net/rfc/closures/object-extension#privateprotected_members_scope

Napsat komentář

Přihlásit se

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: http://www.zdrojak.cz/?p=3513