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.
Nálepky:
PHP 5.4 nepřinese tolik novinek jako PHP 5.3, změny mi ale povětšinou dělají radost.
Odstranění zastaralých obratů
PHP 5.3 označilo řadu obratů jako zastaralých, takže jejich odstranění z PHP 5.4 není žádným překvapením. Co zmizelo?
- Konstrukce
break $var;
- Konfigurační direktiva
safe_mode
a související - Konfigurační direktivy
register_globals
aregister_long_arrays
- Konfigurační direktiva
allow_call_time_pass_reference
- Konfigurační direktiva
highlight.bg
- Konfigurační direktivy
session.bug_compat_42
asession.bug_compat_warn
- Konfigurační direktiva
y2k_compliance
- Funkce
session_is_registered
,session_register
asession_unregister
- Funkce
import_request_variables
- Funkce
define_syslog_variables
a stejnojmenná konfigurační direktiva
Žádný z těchto obratů už léta nepoužívám, takže jejich odstranění vítám, protože do budoucna umožní zjednodušení aplikací nebo snížení nároků na jejich konfiguraci. Konfigurační direktivy magic_quotes_gpc
a magic_quotes_runtime
kupodivu přežily, i když pro první jmenovanou existuje náhrada na úrovni konfigurace a druhá se prakticky nikdy nepoužívala.
Bez náhrady zdá se zmizela i užitečná direktiva safe_mode_exec_dir
.
Nové vlastnosti
$_SERVER['REQUEST_TIME']
nově obsahuje i mikročas (dříve jen čas s přesností na sekundy).- Výchozí hodnota konfigurační direktivy
default_charset
v dodávanémphp.ini
jeUTF-8
(dříveISO-8859-1
). array_combine(array(), array())
vracíarray()
(dřívefalse
).- Třetí parametr funkce
preg_match_all
je nepovinný. To se hodí pro zjištění počtu výskytů regulárního výrazu. $a = null; $a->a = 1;
nyní vyvolá varování (dříve potichu prošlo).<?=
funguje nezávisle na nastaveníshort_open_tag
.- Podpora nepřímého volání metod:
$f = array($obj, 'method'); $f();
. - Přístup k prvku pole vráceného funkcí:
f()[0]
. - Možnost použít
$this
uvnitř anonymních funkcí (netřeba uvádět vuse
). - Možnost zpracovat zdrojáky ve vícebajtovém kódování pomocí
zend.multibyte
(bohužel zatím není povoleno ve verzi pro Windows). - Funkce
http_response_code
vracející momentální HTTP status. - Funkce
header_register_callback
dovoluje zaregistrovat callback zavolaný těsně před posláním hlaviček. - Parametr
$limit
u funkcídebug_backtrace
adebug_print_backtrace
. - Smysl konstrukce
$string[1][0]
mi sice uniká, ale aspoň už nevyvolá chybu. - Některé funkce dříve specifické pro Apache jsou nyní k dispozici i pod FastCGI.
- Funkce
number_format
už dokáže zpracovat i delší oddělovače desetin a tisíců. To dovoluje použít vícebajtové kódování (např. pevnou mezeru v UTF-8) a HTML entity (např.
). - Funkce
hex2bin($data)
(jako protiklad kbin2hex
) je funkčně totožná spack("H*", $data)
.
I v této části jde převážně o čištění jazyka a se změnami souhlasím. Mírně kontroverzní může být <?=
, XML validita PHP skriptů ale stejně zaručena nikdy nebyla i při vypnutém short_open_tag
(např. kód <?php echo "?><"; ?>
je platný PHP skript, ale neplatný XML fragment).
Za zásadní změnu považuji zavedení konstrukce f()[0]
, která byla dlouho požadovaná a stejně dlouho odmítaná např. z důvodů horší čitelnosti. Možná se také ptáte, k čemu je z funkce vracet pole a použít z něj jediný prvek? Mně by se to kdysi hodilo v NotORM, kde byla původně metoda group
dovolující provést třeba i více agregačních funkcí najednou: list($min_id, $max_id) = $table->group("MIN(id), MAX(id)")
. Bohužel se ale neobešla bez dočasné proměnné ani v nejběžnějším případě, kdy se volala jen jedna agregační funkce. S PHP 5.4 by to šlo: $table->group("MIN(id)")["MIN(id)"]
. Nové API $table->min("id")
je ale stejně přehlednější.
Traits
Asi největší novinkou v PHP 5.4 je podpora takzvaných traits. Ty dovolují zmírnit nevýhody jednonásobné dědičnosti tím, že do třídy umožňují vložit definice metod ze společného zdroje nezávislého na dědičnosti. Hodí se to v situaci, kdy chci mít stejnou funkčnost ve více třídách bez společného rodiče. Někdy se to dá vyřešit pomocí metody __call
:
class C { public $common; function __call($name, $args) { if (method_exists($this->common, $name)) { return call_user_func_array(array($this->common, $name), $args); } trigger_error("Call to undefined method " . __CLASS__ . "::$name()", E_USER_ERROR); } }
Zdaleka to ale nejde vždy, např. při implementaci rozhraní s tímto přístupem nepochodíme, protože tam musí být metody definované přímo. Pak nezbývá nic jiného, než je ve třídě všechny potupně zopakovat. PHP 5.4 řeší tento problém pomocí tzv. horizontal reuse:
trait T { function getIterator() { echo "T::getIterator()n"; return new ArrayIterator($this->data); } } class C implements IteratorAggregate { public $data = array(); use T; } $c = new C; var_dump($c instanceof T); // bool(false) foreach ($c as $val) { // T::getIterator() }
Změnu považuji za největší i proto, že přidává nové klíčové slovo. Možnosti jsou ještě širší, především lze definovat řešení kolizí. Zatím je funkčnost popsaná v RFC, píše se ale už i dokumentace.
Jsem zvědav, který framework začne traits využívat jako první. A také který dokumentační nástroj a které IDE se s touto novou vlastností dokáže se ctí vypořádat.
Zákaz změny parametrů u abstraktních konstruktorů
Poměrně zásadní zpětně nekompatibilní změna se týká sjednocení chování při dědění abstraktních konstruktorů s ostatními metodami. Jde o to, že když v potomkovi definujeme abstraktní metodu, musíme zachovat její parametry (můžeme jim přidat výchozí hodnotu, můžeme přidat další parametry s výchozí hodnotou, ale nemůžeme parametry odebrat nebo jim změnit typ):
abstract class A { abstract function __construct($a); } class C extends A { function __construct() { } } // v PHP < 5.4 prošlo, nově vyvolá // Fatal error: Declaration of C::__construct() must be compatible with that of A::__construct()
Na konstruktory se toto omezení nevztahovalo, což nová verze opravuje (a tím zároveň sjednocuje chování s deklarováním konstruktoru pomocí rozhraní). Tento obrat se přitom občas používal, do dokumentace první alpha verze se ale popis této změny bohužel nedostal.
Informace o průběhu uploadu souborů
Už delší dobu se dají informace o průběhu nahrávání souborů od uživatele zobrazovat pomocí extenze APC. Nově to jde i jen pomocí session proměnných. Vzniklo k tomu několik konfiguračních direktiv začínajících na session.upload_progress.
, pomocí kterých se dá chování ovlivnit.
Pokud je sledování průběhu nahrávání povoleno, tak už stačí jen metodou POST poslat pole s názvem ini_get("session.upload_progress.name")
. To způsobí vytvoření proměnné $_SESSION[ini_get("session.upload_progress.prefix") . $_POST[ini_get("session.upload_progress.name")]]
, která bude obsahovat pole se všemi dostupnými informacemi. Detailně to rozebírá příklad.
Změny v extenzích
- V cURL lze omezit rychlost stahování a odesílání dat.
- Funkce
scandir
nyní dovoluje netřídit výsledek. Tuto funkci jsem už nicméně dávno vyměnil za šikovnějšíglob
. - Do extenze Hash přibyly hašovací funkce Joaat a FNV-1.
- Do extenze Intl přibyla třída
Spoofchecker
kontrolující zaměnitelné řetězce, např."http://www.paypxD0xB0l.com"
. - Z MySQL zmizela funkce
mysql_list_dbs
. Výsledkymysqli_result
lze konečně procházet pomocíforeach
. - OpenSSL nově podporuje šifrování pomocí AES.
- Reflexi přibyly metody
ReflectionClass::isCloneable
,ReflectionExtension::isPersistent
aReflectionExtension::isTemporary
. Vznikla třídaReflectionZendExtension
. - Výchozí hodnota
session.entropy_file
je/dev/urandom
nebo/dev/arandom
, pokud tyto „soubory“ existují v době kompilaci PHP. - V SPL přibyly metody
RegexIterator::getRegex
,SplObjectStorage::getHash
a třídyCallbackFilterIterator
aRecursiveCallbackFilterIterator
.
V extenzi JSON, která je v poslední době velmi populární, je změn více:
- Přibylo rozhraní
JsonSerializable
deklarující metoduJsonSerializable::jsonSerialize
, jejíž výstup se předá funkcijson_encode
. - Funkce
json_decode
nově umí vracet velká čísla jako řetězce – to se může hodit třeba u Twitter API. Funkcejson_encode
se obdobně naučila převádět číselné řetězce na JSON čísla. - Funkce
json_encode
nyní dokáže výstup formátovat pomocí bílých znaků a nemusí ošetřovat znak/
.
Změny příkazové řádky
- Přibyla volba
--rz
poskytující informace o Zend extenzích (obdoba třídyReflectionZendExtension
). - Dále vznikly konfigurační direktivy
cli.pager
acli.prompt
. - V interaktivním režimu by také mělo fungovat nastavování konfiguračních direktiv pomocí
#inisetting=value
, platí to ale jen při práci přes Readline.
Další novinky
Kromě těchto změn, které jsou důležité při vytváření aplikací, došlo také k řadě vylepšení ve výkonnosti a paměťové náročnosti PHP. V méně používaných extenzích došlo k několika dalším změnám, které tento článek nepopisuje.
Co mi ještě chybí
Když už lze volat f()[]
, tak bych také ocenil obrat (new C)->f()
, který by se hodil u fluent interface. Nemožnost pracovat s výsledkem operátoru new
se dá různými způsoby obejít, je to ale značně krkolomné:
// první možnost function identity($x) { return $x; } identity(new C)->f(); // druhá možnost class C { static function create() { return new self; } } C::create()->f();
Této vlastnosti bychom se v PHP 5.4 měli ještě dočkat.
Občas by se mi také hodilo deklarovat návratový typ metod. Užitečné by to bylo hlavně u dědičnosti, kdy by se dalo odvozeným třídám přikázat, aby vracely stejný typ objektu. Této změny se podle mě zatím nedočkáme.
Závěr
Vydaná alpha na mě působí celkem vyzrálým dojmem. Pár chyb se sice již objevilo, ale věřím, že nebudou nijak závažné a další vývojová verze vyjde poměrně brzy. Změny na mě také působí poměrně uceleným dojmem, takže si myslím, že příliš dalších novinek se v PHP 5.4.0 už neobjeví.
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ří skripthack.php
. Tento skript pak může pracovat se souboremavatar.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 ofnull
/''
/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).
Uplne mi vre krev:
$a = null; $a->a = 1;
nyní vyvolá varování (dříve potichu prošlo) – Projde, pokud je programator prase – sE_STRICT
dostanu „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 zpusobemAd
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: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
}
Ž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ě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í.
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"
– 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.
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;
vsnew Foo($bar);
)).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
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
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
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 RozsirovanyObjekt();
$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 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.$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 NetteObject.
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.
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ší.
Nejspíš by bylo dobré, sepsat na to RFC pro PHP, pokud si myslíš, že by se to hodilo :)
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 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…
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ř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_mode
jsem v této diskusi už popsal. Spíš to na mě působí, jako byste si to spletl právě sopen_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.
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.
Nejjednodušší záplata je
extract($_REQUEST)
, ale obvykle je skutečně lepší přepis.Presne tak, kdyz uz se do toho bude sahat, je lepsi to udelat hezky ciste. :-)
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é
Č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:
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_quotes_gpc
zůstane, ale bude vracet vždyfalse
).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
a ne
?
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.
__invoke
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