Komentáře k článku
PHP 5.4 přináší změny a nové jazykové konstrukce
Vyšlo PHP 5.4.0, a i když je zatím ve verzi alpha, podíváme se na novinky v tomto jazyce, na nové konstrukce, odstraněné konstrukce a další změny, kterých sice není tolik jako ve verzi 5.3, ale jsou zajímavé. Změny pro čtenáře Zdrojáku sumarizoval a okomentoval Jakub Vrána.
safe mode
a cim ho nahradit?
Re: safe mode
safe_mode robí viac problémov ako úžitku
Re: safe mode
Napriklad akych ?
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ří skripthack.php. Tento skript pak může pracovat se souboremavatar.jpg.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.
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.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ší.
Re: safe mode
Zajimavy je taky mod_ruid pro apache…
Re: safe mode
Oddělení uživatelů na sdíleném hostingu řeší lépe
open_basedir, ostatní vlastnosti jsou zrušeny.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 :(
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 …
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 :)
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 ofnull/''/falseinto 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.
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 :)
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.
Re: PHP 5.4 přináší změny a nové jazykové konstrukce
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
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…
$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).
Argh!
Uplne mi vre krev:
$a = null; $a->a = 1;nyní vyvolá varování (dříve potichu prošlo) – Projde, pokud je programator prase – sE_STRICTdostanu „Strict standards violation“. Tedy opet neco navic pro deti, ktere se dostaly k PHP a mysli si, ze umi programovat.<?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 koderaCo se pak tyce dalsich direktiv… nekoukal jsem do podrobnosti, ale ponekud me zarazi:
f()[0]. Skutecne mohu vratit jen prvni prvek pole? Nebo jakykoliv pomocif()[$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 zpusobemRe: 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.
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.
Re: Argh!
a u closures bu bolo dobré zrušiť nutnosť používať use.
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.
Re: Argh!
neni to zlý návrh v iných jazykoch sa to bežne používa.
napr.:
using (var stream = File.Open(@“C:subor.dat“, FileMode.OpenRead))
{
var text = new StreamReader(stream).ReadLine(); //čítam textový reťazec
stream.Position = 56;
var num = new BinaryReader(stream).ReadInt64(); //čítam číslo ktoré je uložené binárne
}
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ě.
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ť.
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…
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.
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ějaká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í.
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.
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…
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.
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.
Re: Argh!
a nebo je implementovany tak, jak si ho implementuju ja
Re: Argh!
hele wole, co to blábolíš?
Re: Argh!
1. Direktiva
safe_mode_exec_dirje 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.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.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"– nikolivinclude("a"), píšuexit– nikolivexit()a píšunew A– nikolivnew A(). Podle vaší argumentace byste přesně vy byl ten případ, který nechápe, co se děje. Protoženew A()není zavolání konstruktoru – je to vytvoření objektu (při čemž se volá konstruktor). A vytvoření objektu vyjadřuje operátornew.5. Úplně by stačilo přečíst si článek, na který reagujete.
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!
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í).
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;vsnew Foo($bar);)).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
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!
Re: Argh!
Také mám raději zápis new $a(), protože se tam prostě volá konstruktor.
Re: Argh!
Volání konstruktoru nezáleží na tom, jestli tam závorky jsou nebo nejsou, ale na tom, jestli je konstruktor definovaný.
Re: Argh!
ale stale je „konstruktor“ pevne spjat s vytvarenim instance, at uz ho programator sam vyrobil nebo ne. zavorky jsou preci fain :)
Re: Argh!
Ale houbelec, jak víš, že ona třída má konstruktor?
Re: Argh!
Kazda trida ma konstruktor, at uz je definovan a nebo ne.
Re: Argh!
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
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
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.
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.
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).
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.
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.
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 RozsirovanyObjekt();
$o->setTrait($trait);
//pouziti
$o->getTrait()->volanaMetoda();
Za případné syntaktické chyby se omlouvám.
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 volatforeach ($o->getTrait() as $val)místo elegantníhoforeach ($o as $val)). Další nevýhodou je, že$o->getTrait()nevidí neveřejné vlastnosti a metody rozšiřované třídy.Re: Argh!
$o->getTrait()->volanaMetoda()je pouze příklad. Pokud nějaký kód bude s$traitpracovat, 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.
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).
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
__callmetodami 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 :)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.
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(Repository $repository){
$this->repostiory=$repository;
}
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.
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.
Re: Argh!
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
Bude finally
Ví někdo, jestli se v 5.4. objeví i finally v try-catch bloku?
Re: Bude finally
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ší.
Re: Bude finally
Nejspíš by bylo dobré, sepsat na to RFC pro PHP, pokud si myslíš, že by se to hodilo :)
Re: Bude finally
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…
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…
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.
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.
Re: Sejfmod
Direktiva
safe_mode_exec_dirse safe mode vlastně vůbec nesouvisí. Klidně by mohla být na nastavenísafe_modenezávislá a mohla by se jmenovat třebaallowed_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 iopen_basedir(který zůstává, protože hlavní smysl safe mode zastává mnohem lépe).Nefunkčnost a nebezpečnost
safe_modejsem v této diskusi už popsal. Spíš to na mě působí, jako byste si to spletl právě sopen_basedir.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.
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.
Re: Register_globals
Nejjednodušší záplata je
extract($_REQUEST), ale obvykle je skutečně lepší přepis.Re: Register_globals
Presne tak, kdyz uz se do toho bude sahat, je lepsi to udelat hezky ciste. :-)
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é
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…
Re: file upload progress
Velikost souboru nelze zjistit, u multipart/form-data se u jednotlivých částí délka neuvádí.
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á?
Re: Traits a zapouzdření
Ano:
Traits je chaba nahrada vicenasobne dedicnosti
spise to zavadi do kodu zmatek, proc se lide kolem vyvoje php neinspirovali u c++ ? ;)
Re: Traits je chaba nahrada vicenasobne dedicnosti
ale urcite se inspirovali… a pak jeste asi u dalsich 10ti jazyku :D
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 {
> }
??
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íš.
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.
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.
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_quotes_gpczůstane, ale bude vracet vždyfalse).To považuji za ideální stav.
Re: Magic quotes nejspíš zmizí
A je to pryč:
http://svn.php.net/viewvc?view=revision&revision=313575
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 { }?
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.
Re: PHP versus Python
Než začnete něco srovnávat, musíte to nejprve znát.
__invokesys.exitTo, ž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.
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
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.
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