Názory k článku
PHP 5.4 přináší změny a nové jazykové konstrukce

a cim ho nahradit?

safe_mode robí viac problémov ako úžitku

Napriklad akych ?

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.

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

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.

"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ší.

Zajimavy je taky mod_ruid pro apache...

Oddělení uživatelů na sdíleném hostingu řeší lépe open_basedir, ostatní vlastnosti jsou zrušeny.

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 :(

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

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

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.

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 :)

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.

A právě takové "hecy ~ kecy" snižují kvalitu článků o PHP na rootu :( Daleko důležitější než nějaké PR o NotORM či Nette je, že existuje testovací nástroj pro traity - PHPUnit 3.6 http://sebastian-bergmann.de/archives/906-Testing-Traits.html

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

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

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.

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.

a u closures bu bolo dobré zrušiť nutnosť používať use.

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.

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
}

Ž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ě.

"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ť.

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

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.

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

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.

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

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

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.

a nebo je implementovany tak, jak si ho implementuju ja

hele wole, co to blábolíš?

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

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!

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

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

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!

Také mám raději zápis new $a(), protože se tam prostě volá konstruktor.

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

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

Ale houbelec, jak víš, že ona třída má konstruktor?

Kazda trida ma konstruktor, at uz je definovan a nebo ne.

To není pravda. V PHP se konstruktor říká metodě pojmenované __construct (nebo z důvodu zpětné kompatibility metodě pojmenované stejně jako třída). Takže když třída tuto metodu nedefinuje, tak říkáme, že třída nemá konstruktor.

http://www.php.net/manual/en/language.oop5.decon.php

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.

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.

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

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.

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.

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.

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.

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

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

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 :)

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 Nette\Object.

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.

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.

jak se to má s těmi traity, rozhraními a vícenásobnou dědičností: http://forum.nette.org/cs/7291-vicenasobna-dedicnost-proc-ji-nezkusit-impementovat-v-nette-kdyz-neni-v-php#p54852

Ví někdo, jestli se v 5.4. objeví i finally v try-catch bloku?

Na 99 % ne. Jinak by to už dávno bylo tady: https://wiki.php.net/todo/php54
Navíc pro to ani neexistuje RFC (https://wiki.php.net/rfc), takže to zřejmě ani nikdo aktivně neřeší.

Obávám se, že to je málo. Vzhledem k tomu, že report na tohle téma tam hnije už víc než 6 let: https://bugs.php.net/bug.php?id=32100 by to chtělo někoho, kdo by dodal diff...

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.

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.

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.

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.

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

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

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

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á?

Ano:

trait T {
    function f() {
        return $this->x;
    }
}

class C {
    use T;
    private $x = 3;
}

$c = new C;
echo $c->f(); // vypíše 3 

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

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

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 {
> }

??

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

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.

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.

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.

A je to pryč:

http://svn.php.net/viewvc?view=revision&revision=313575

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
{
}

?

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.

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.

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

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.

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