ugrás a tartalomhoz

Megjelent a PHP 5.4

Bártházi András · 2012. Már. 2. (P), 11.59

A PHP 5.4 verziójának kiadásával izgalmas (és régóta hiányzó) dolgok jelentek meg a nyelvben, melyek nagy részét szívesen fogom szinte minden nap használni (majd ha élesben tényleg át lehet állni rá). Sok olyan dolog is ki lett végre kukázva, melyek már teljesen elavult nyelvi elemnek számítottak. Megpróbáltam összegyűjteni azokat a lényegesebb változásokat, melyek a leginkább tetszenek.

Beépített webszerver

Éles környezetben nem ajánlott a futtatása, de ezentúl egy webszerver is be van építve a PHP-be. Így indítható:

php -S localhost:8000

Ebben az esetben az adott könyvtár lesz a weboldal gyökere, onnan alapból az index.php vagy index.html fájlok kerülnek kiszolgálásra. Paraméterként megadható egy PHP fájl neve is, ami „router”-ként fog működni. Bővebben: Features: command line webserver.

Könnyítések

Ide azokat az újdonságokat soroltam, melyek nélkül lehet élni, de átláthatóbb, tömörebb, „szebb” kódot eredményez a használatuk (a tömör alatt itt nem a Perl-féle 8 byte-ba minden algoritmus belefér szintakszisra gondolok).

A JavaScriptben megszokott tömör tömb deklarációt a PHP-ben sem kell már nélkülöznünk. Ezentúl elhagyhatjuk az array() kulcsszót, és helyette szögletes zárójelet használhatunk. A JavaScripthez képest eltérés, hogy az asszociatív tömböknél is szögletes zárójelet kell használni (bár ebben semmi meglepő nincs):

$a = [1, 2, 3];
$b = ['foo' => 'orange', 'bar' => 'apple', 'baz' => 'lemon'];

A PHP-ből már nagyon hiányoltam, azt az – általam – régebben a Perlben, manapság a JavaScriptben gyakran használt nyelvi lehetőséget (de a Java, Ruby és minden más modernebb nyelv is ismeri), mely lehetővé teszi, hogy egy frissen példányosított osztálynak egyből meghívjuk egy metódusát:

$myCar = (new Car)->setSpeed(100)->setColor('blue');

JavaScriptben, jQuery-ben sok ilyet láthatott már mindenki. Ha a metódusok visszatérési értéke minden esetben a példányra mutat (return $this), akkor válik lehetővé ennek a megoldásnak a hatékony használata.

Nagyon hasonlít erre az az eset, amikor egy függvény tömb értékkel tér vissza, és ennek a tömbnek egyből egy elemére szeretnénk hivatkozni. Ezentúl ez is lehetséges:

function fruit ()
{
    return array('a' => 'apple', 'b' => 'banana');
}
 
echo fruit()['a'];

Szintén könnyítés, és igazából nem is értem, hogy eddig miért nem volt rá lehetőség, hogy a bináris számokat ezentúl tömören le tudjuk írni:

$x = 0b001110;

Trait

A trait-ek (magyarul jellemző, jellemvonás) szimplán összegyűjtött metódusok, melyeket egy osztály deklarációjakor használhatunk. A több helyen felhasználható, ismétlődő kódrészleteket lehet így egy helyre kigyűjteni, egyik példa lehet a Singleton design pattern megvalósítása:

trait Singleton
{
    public static function getInstance()
    {
        …
    }
}

class A
{
    use Singleton;
    …
}

class B extends ArrayObject
{
    use Singleton;
    …
}

A::getInstance();
B::getInstance();

Típus kényszerítés függvény paraméterekre

A PHP 5, illetve 5.1 óta egy függvénynél kötelezővé tehetjük, hogy az egyes paraméterek egy adott osztályba tartozzanak, vagy pedig szigorúan tömbök legyenek. Az 5.4-ben lehetőség van a függvény típus jelölésére is a callable kulcsszóval:

function foo(callable $cb)
{
    $cb();
}

Teljesítmény

Vannak a PHP-nek olyan részei, melyek használatát illik mellőzni (nem csak teljesítmény okokból), ennek ellenére elég sok olyan kód fellelhető szerte a világban, melyek nem így tesznek. A PHP 5.4-ben pár ilyen megoldásnak is javult a teljesítménye.

A $GLOBALS tömb inicializációja egy erőforrásigényes művelet, mind a sebesség, mind a memóriahasználat szempontjából. A PHP 5.4-ben a tömb csak első használatkor inicializálódik ezentúl.

A @ operátor (ejtsd: SILENCE!) ezentúl egy kicsit gyorsabb lesz.

Elfelejthetjük!

Eltávolításra került a PHP-ből a safe mode, továbbá a y2k_compliance, a magic_quotes_gpc, a magic_quotes_runtime, a magic_quotes_sybase, a register_globals, a register_long_arrays, az allow_call_time_pass_reference kapcsolók!

Továbbiak

Általában véve (a marketingszöveg alapján) a PHP 5.4 teljesítménye érezhetően gyorsabb, kisebb a memóriafoglalása és 100 feletti hibát javít. A teljes lista elérhető itt: http://php.net/ChangeLog-5.php#5.4.0

 ■
2

Teljesítmény

Hidvégi Gábor · 2012. Már. 2. (P), 12.46
PHP-gyorsítónak eddig az eAcceleratort használtam, de a Zend alaprendszer változásai miatt az 5.4-hez már nem lehet lefordítani, emiatt kipróbáltam az APC kiegészítőt. Az eddigi tesztjeim alapján 5-10%-os gyorsulást tapasztaltam összetett scriptek futtatásakor az 5.3.10-es PHP-hoz képest.

A Zend más kiterjesztéseknél is okozhat gondot, jellemzően azoknál, amelyek fejlesztése szünetel, például a memcached sem fordul le (a memcache viszont igen).
5

az apc-ben meg vannak ismert

Tyrael · 2012. Már. 2. (P), 13.55
az apc-ben meg vannak ismert hibak az 5.4-gyel hasznalva.

Tyrael
7

Tudsz ajánlani alternatívát?

Hidvégi Gábor · 2012. Már. 2. (P), 14.05
Tudsz ajánlani alternatívát? Esetleg tudnál segíteni az eAccelerator megjavításában?
8

szerintem egyszerubb

Tyrael · 2012. Már. 2. (P), 14.59
szerintem egyszerubb megvarni, amig a blocker apc bugokat javitja Gopal.
http://bit.ly/z5iqWH
szerintem meg igy is az apc all a legkozelebb a mukodeshez (xcache, eAccelerator le sem fordul, raadasul egyik sincs a php esernyoje alatt, ergo nem akarjak/tudjak a core fejlesztok direktben javitani a hibat az adott extensionben.
A Zend Server/Optimizer az ami szerintem meg belathato idon belul tamogatni fogja az 5.4-et.

ps: ha megis belefognal az eAccelerator peccselesebe, akkor megprobalkozhatsz az ottani levelezolistaval, ha ott nem kapsz segitseget, akkor erdemes lehet meg irc-n megkerdezni (efnet #php.pecl) hatha valaki nagyon raer es tud segiteni.

Tyrael
13

zend optimizer

joed · 2012. Már. 2. (P), 22.44
Andi Gutmans elejtett tweetje szerint már a jövő héten elérhetőek lesznek 5.4-es konténerek a phpcloud.com-on. Ebből lehet arra következtetni, hogy a Zend Server 5.4-es verziója is hamarosan kigurul, rendre Zend Optimizerrel.
1

Köszi az összefoglalót

szilagyif · 2012. Már. 2. (P), 12.27
Köszi az összefoglalót András!

A könnyítések bekezdésben leírt pontokat én is nagyon hiányoltam, főleg a method chaininget és a függvényhívásnál visszakapott tömb elemeire való közvetlen hivatkozást.

Sajnos az még nagyon távoli, hogy az éles rendszerekkel is átálljunk 5.4-re.
3

Köszi az összefoglalót, nem

ochronus · 2012. Már. 2. (P), 13.10
Köszi az összefoglalót, nem is olyan rég én is írtam errről:
http://blog.kodfejtok.hu/php-5-4-izelito
4

akkor mar en is belinkelem a

Tyrael · 2012. Már. 2. (P), 13.54
akkor mar en is belinkelem a sajat eloadasomat:
http://webkonf.org/2011/eloadasok.html#php5.4

Tyrael
6

Ez jó, köszi! Jó anyag. Főleg

ochronus · 2012. Már. 2. (P), 14.00
Ez jó, köszi! Jó anyag. Főleg a release processről szóló infó volt újdonság nekem
14

hehe

joed · 2012. Már. 2. (P), 22.45
Hehe, pont kérni akartam a linket :D
9

Amit én hiányolok, hogy a

inf · 2012. Már. 2. (P), 16.59
Amit én hiányolok, hogy a tömböket is referencia szerint adja át, ne kelljen mindenhol kitenni a &-et, ahol ilyet akarok. (Bár tömböket már ritkán használok gyűjteménynek.)

Amit szintén hiányolok, hogy string, integer, stb típusokat nem lehet ellenőriztetni (bár ezt már lehet, hogy javították, nem követem az új verziókat).

Ami szintén jó lenne, ha a példányváltozó deklarálásánál meg lehetne adni a típusát és az értékadásnál ellenőrizné a php, hogy tényleg abba a típusba tartozik e, illetve ez az automatikus kiegészítésnél is nagy segítség lenne, mert pl netbeans-nél ha most setter-rel állítasz be valamit, akkor annak elfelejti a típusát, és nem ajánl fel semmit.

Ha ezeket sikerülne megvalósítani, akkor sokkal élvezhetőbb nyelv lenne.
11

SplTypes

Gixx · 2012. Már. 2. (P), 17.31
Azt hiszem, neked az Spl tipusokra van szükséged.
12

Vagy a Javára :)

tgr · 2012. Már. 2. (P), 18.52
Vagy a Javára :)
15

vagy C#-ra :)

joed · 2012. Már. 2. (P), 22.47
nem biztos, hogy a PHP erősen típusos nyelv akarna lenni
17

Attól, hogy belekerülne

inf · 2012. Már. 2. (P), 22.55
Attól, hogy belekerülne néhány típusellenőrzéssel kapcsolatos kényelmi funkció még korántsem lenne erősen típusos...

(Amiket felsoroltam szerintem pillanatok alatt bele lehetne tákolni a mostani PHP-ba.)
19

a levlistan ki lett fejtve

Tyrael · 2012. Már. 2. (P), 23.59
a levlistan ki lett fejtve tobbszor, hogy a gyenge es az eros tipusossag keverekebol akkor is erosen tipusos nyelv lesz, ha az eros tipusos opcionalis.
pl. behuzol egy ZF vagy PEAR libet, ha valahol hasznal scalar typehintet, akkor onnantol kezdve te is elkezded ugyanazt a tipushintelest alkalmazni, hogy mar te sem kaphass rossz tipust, ezaltal megakadalyozando hogy rossz tipust adj a lib fuggvenynek, vagy irsz egy csomo boilerplate kodot, ahol a string 1-bol int 1-et csinalsz, csak hogy nehogy hanyat dobja magat a libben levo fuggveny.
mindket esetben befolyasolta a hivo kornyezetet(egeszen a hivasi graf tetejeig) a teny, hogy valahogy egy eldugott helyen typehintet hasznalt valaki.
az hogy az osztalyok/tombok kapcsan ez a szigoru tipusossag a typehint kapcsan nem okozott mar eddig is nagyobb fejfajast, csak annak koszonheto, hogy az atlag fejleszto nem teved akkorat, hogy rossz tipusu objectet at, vagy ha igen, akkor meg orul is neki, hogy felrobbant a kod, mert nem lehet mast tenni abban a helyzetben.
ha viszont ugyanez a hiba valtodna ki, mert valahol "1" ment at 1 helyett, az elegge kicsapna a biztositekot egy csomo embernel, mert egyszeruen nem ehhez vannak szokva, nem igy mukodik ez a nyelv.

Tyrael
23

ha viszont ugyanez a hiba

inf · 2012. Már. 3. (Szo), 07.19
ha viszont ugyanez a hiba valtodna ki, mert valahol "1" ment at 1 helyett, az elegge kicsapna a biztositekot egy csomo embernel, mert egyszeruen nem ehhez vannak szokva, nem igy mukodik ez a nyelv.

Lehet, hogy kivétel vagyok, de nehezen tudom elképzelni azt, hogy "1" megy át valahol 1 helyett. Az űrlapokban stringként megy át minden, ott egyértelmű, hogy azt kapok, adatbázisban szintén, a SOAP-ban lehet típust konvertálni, szóval ott a wsdl-ben megadott típus fog átmenni, az összes többi esetben meg látod a kódot, amiből az érték jön, de a biztonság kedvéért le lehet ellenőrizni mondjuk is_int-el, vagy konvertálni...

a levlistan ki lett fejtve tobbszor, hogy a gyenge es az eros tipusossag keverekebol akkor is erosen tipusos nyelv lesz, ha az eros tipusos opcionalis.

Én nem vagyok ellene a típusosságnak, szóval engem ez egyáltalán nem zavarna, persze el tudom képzelni, hogy sokakat igen.
26

"Lehet, hogy kivétel vagyok,

Tyrael · 2012. Már. 3. (Szo), 16.00
"Lehet, hogy kivétel vagyok, de nehezen tudom elképzelni azt, hogy "1" megy át valahol 1 helyett."
ahogy te is leirtad, az esetek nagy reszeben az adatok amikkel dolgozik a scripted string tipusuak lesznek, fuggetlenul attol, hogy szamokat tartalmaznak.
ha bevezeted a szigoru tipusossagot a php-be(ezaltal megszunteted a type jugglingot), onnantol kezdve minden ilyen esetben allandoan inicializalas elott explicit kellene castolgatnod a valtozoidat, vagy kapnad a warning/recoverable errorokat a type mismatchre.

"Én nem vagyok ellene a típusosságnak, szóval engem ez egyáltalán nem zavarna, persze el tudom képzelni, hogy sokakat igen."
en pedig hetero vagyok, de ezert nem kampanyolnek a buzibar profilvaltasa ugyeben.
mindenki hasznalja a sajat izlesenek megfelelo nyelvet, es ne akarja raeroltetni masokra a sajat preferenciait, kulonosen akkor ne, hogyha ezzel a velemenyevel az adott kozossegben egy nagyon apro kissebbseget kepvisel.

Tyrael
33

+1

zzrek · 2012. Már. 3. (Szo), 22.38
Én is hetero vagyok.
Ja, és szerintem (is) jól áll a PHP-nek, hogy nem típusos
34

Haha, én is hetero vagyok,

inf · 2012. Már. 3. (Szo), 23.41
Haha, én is hetero vagyok, szerintem meg tökmindegy, én úgyis minden esetben ellenőrizni fogom a típust ha valaminek értéket adok. ;-)
18

"Amit én hiányolok, hogy a

Tyrael · 2012. Már. 2. (P), 23.54
"Amit én hiányolok, hogy a tömböket is referencia szerint adja át, ne kelljen mindenhol kitenni a &-et, ahol ilyet akarok. "
miert lenne ez jo? azon kivul, hogy eltorne egy csomo kodot? melyik masik nyelvben lattal erre peldat?

"Amit szintén hiányolok, hogy string, integer, stb típusokat nem lehet ellenőriztetni "
miert ne lehetne? is_int, is_string, etc.
vagy type hintingre gondolsz? aktiv (ertsz tobbszaz emailt generalo) vita zajlik most is (mar sokadszor) az internals levlistan, az az erzesem, hogy be fog kerulni a scalar typehint a nyelvben, viszont nem a jelenlegi class/array mintajara strong typinggal, hanem a scalarokra php-ban jellemzo weak typinggal (azaz ha int/bool/string-re fogsz hintelni, akkor eltero tipus eseten nem recoverable errort fog dobni a php, hanem megprobalja castolni a valtozot a jelenlegi type juggling szabalyai szerint).

"(bár ezt már lehet, hogy javították, nem követem az új verziókat)."
hat oo ize, akkor talan nem kellene ilyen kategorikus kijelenteseket tenni.

"Ami szintén jó lenne, ha a példányváltozó deklarálásánál meg lehetne adni a típusát és az értékadásnál ellenőrizné a php, hogy tényleg abba a típusba tartozik e"
bar paran agalnak ellene, de a core fejlesztok reakciobol biztosra veheto, hogy szigoru/eros tipusossag sosem fog bekerulni a nyelvbe.
ha erdekel hogy miert, akkor lasd levlista.
ha megis szukseged van ra, akkor van egy csomo szigorubban tipusos nyelv, mint a php.

"illetve ez az automatikus kiegészítésnél is nagy segítség lenne, mert pl netbeans-nél ha most setter-rel állítasz be valamit, akkor annak elfelejti a típusát, és nem ajánl fel semmit."
ez mitol oldodna meg? a netbeans tovabbra sem fogja erteni, hogy mit csinal a settered, illetve lehet olyan logika a setteredben, hogy parametertol fuggoen mas-mas valtozoba teszi a bealitani kivant valtozot, innentol kezdve megint nem tudhatja a netbeans, hogy milyen tipust engedhetsz.
viszont a setterben megadott typehint (vagy docblock, ami mar jelenleg is tamogatott a scalar tipusokra is) elegendo informaciot hordoz ahhoz, hogy az okos IDE fel tudja ajanlani a kiegeszitest.

"Ha ezeket sikerülne megvalósítani, akkor sokkal élvezhetőbb nyelv lenne."
nem, akkor egy maszlag lenne, persze ez csak az en velemenyem.
csodalkozom, hogy a thread kezelest nem hoztad fel, vagy hogy alakitsunk minden errort/warningot/notice-t exceptionne, es hogy kukazzuk le a @ operatort.

Tyrael
21

ne adj

joed · 2012. Már. 3. (Szo), 01.41
csodalkozom, hogy a thread kezelest nem hoztad fel, vagy hogy alakitsunk minden errort/warningot/notice-t exceptionne, es hogy kukazzuk le a @ operatort.

Ne adj ötleteket! :D
22

"Amit én hiányolok, hogy a

inf · 2012. Már. 3. (Szo), 06.49
"Amit én hiányolok, hogy a tömböket is referencia szerint adja át, ne kelljen mindenhol kitenni a &-et, ahol ilyet akarok. "
miert lenne ez jo? azon kivul, hogy eltorne egy csomo kodot? melyik masik nyelvben lattal erre peldat?

Azt hiszem az 5-ös verzióban változtatták meg a PHP-t olyanra, hogy az összes objektumot alapértelmezetten referenciaként adja át, ne pedig másolja őket. Sajnos a tömböket kihagyták, ezért azok még mindig másolódnak alapértelmezetten, aminek meg nincs túl sok értelme az esetek döntő többségében... (Ha objektumba zárod a tömbödet, akkor viszont megoldódik ez a probléma.)
A másik gond a tömb referenciakénti átadásával, hogyha értéket adunk át, akkor elszáll hibával:

class ArrayChanger {
	public function append(array &$subject) {
		$subject[] = count($subject);
	}
}

$appender = new ArrayChanger();
$x = array();
$appender->append($x); // ok
$appender->append(array()); // itt elszáll hibával, mert nem változót adtam neki, hanem értéket
A harmadik gond a tömbökkel egy tervezési hiba: két funkciót látnak el: Map és List. Melyik másik nyelvben láttál még ilyet?


ez mitol oldodna meg? a netbeans tovabbra sem fogja erteni, hogy mit csinal a settered, illetve lehet olyan logika a setteredben, hogy parametertol fuggoen mas-mas valtozoba teszi a bealitani kivant valtozot, innentol kezdve megint nem tudhatja a netbeans, hogy milyen tipust engedhetsz.

Szerintem ezt erősen félreértetted...

class MyTest {
	public function helloWorld() {
		echo('Hello world!');
	}
}

class Example {
	protected MyTest $test;
	
	public function __construct() {
		$this->test = new MyTest();
	}
	
	public function void doSomething() {
		$this->test->helloWorld();
	}
}
Egy ilyen szerkezetnél a doSomething-ben meg tudná mondani az automatikus kiegészítés, hogy a $this->test az MyTest típusú, és így fel tudná ajánlani a helloWorld metódust. (Ami talán problémás lehet, hogy az autoload mikor töltse be az adott osztályt, nyilván az lenne a legjobb, ha értékadáskor, amikor ellenőrizni kell a típust...)

nem, akkor egy maszlag lenne, persze ez csak az en velemenyem.

ha megis szukseged van ra, akkor van egy csomo szigorubban tipusos nyelv, mint a php.

Imho a PHP már most egy nagy maszlag, a fejlesztői meg szerintem maguk sem tudják, hogy mit akarnak. Dönthettek, hogy bevezetik a típusellenőrzést vagy sem, nem tudták eldönteni, így született a mostani köztes megoldás, ami minden, csak nem jó. Ez olyan, hogy vagy megcsinálom rendesen, vagy sehogy... (Egyébként ez a káosz érződik az egész nyelvben, nem csak a típusellenőrzésnél, de ez az én véleményem...)

csodalkozom, hogy a thread kezelest nem hoztad fel, vagy hogy alakitsunk minden errort/warningot/notice-t exceptionne, es hogy kukazzuk le a @ operatort.

Thread-re nincs szükség a PHP-ban, ha csak weblap generálásra használod, amire a nyelv amúgy hivatott... Miért is kéne mindent exception-re alakítani?
27

Azt hiszem az 5-ös verzióban

Tyrael · 2012. Már. 3. (Szo), 17.03
Azt hiszem az 5-ös verzióban változtatták meg a PHP-t olyanra, hogy az összes objektumot alapértelmezetten referenciaként adja át, ne pedig másolja őket.

kicsit ennel osszetettebb volt a valtozas, de felhasznaloi szempontbol valoban ez az egyik lathato kovetkezmenye.

Sajnos a tömböket kihagyták, ezért azok még mindig másolódnak alapértelmezetten, aminek meg nincs túl sok értelme az esetek döntő többségében...

azzal ugye tisztaban vagy(szerintem irtam mar itt neked weblaboron regebben), hogy a php a copy-on-write modellt alkalmazza, innentol kezdve a referenciakkal valo jatszadozassal nem igazan lehet memoriat sporolni az esetek 99%-ban.
ha erdekel ez mukodes kozben, akkor itt egy pelda:
http://codepad.viper-7.com/8OGxgq

ahogy latod a tomb masolasa minimalis plusz memoriafoglalassal jar, egeszen addig, amig nem modositok a tombon, mert fizikailag akkor kell csak masolnia, addig ugyanarra a memoriateruletre mutat a masolat tomb is.

A másik gond a tömb referenciakénti átadásával, hogyha értéket adunk át, akkor elszáll hibával

ez by design ilyen, erteket nem adhatsz at referenciakent, mivel a hivo kornyezetben az array()-t nem a rendeled hozza semilyen valtozohoz, ezert nem lesz mire hivatkoznod a referenciakent.
az $appender->append($foo=array()); nyilvan mukodne.

de meg mindig kivancsi lennek, hogy a peldadban miert erne meg referenciakent atadni a temp tombot, az a gyanum, hogy csak memoriat szeretnel vele sporolni (a referenciakenti atadas masik elonyet az jelentene, hogy az igy atadott parametert a meghivott kod modositani tudna, de te pont azt szeretned, hogy a hivo kornyezetben ne kelljen valtozot letrehoznod, ezt ebben a formaban nem tudnad kihasznalni), ami amint mar emlitettem felesleges, hiszen a COW miatt nem sporolsz semmit.

Szerintem ezt erősen félreértetted...

ebben a peldadban nincs setter, az eredeti postodban arrol beszeltel:
mert pl netbeans-nél ha most setter-rel állítasz be valamit, akkor annak elfelejti a típusát, és nem ajánl fel semmit.

en erre probaltam valaszolni.
a mostani peldadnal maradva: nekem (a void, illetve MyTest typehint nelkul) ez szepen mukodik PHPStorm-ban, siman felajanlja a helloWorld metodust (gondolom a __construct-ban szereplo ertekadas miatt)
ha kiszedem a constructort, akkor a kovetkezo docblock szinten mukodik nalam:
/**
* @property MyTest $test
*/

tovabbi infoert katt ide (ez nyilvan setterre is mukodik szepen).

Imho a PHP már most egy nagy maszlag, a fejlesztői meg szerintem maguk sem tudják, hogy mit akarnak.

az evek soran volt 1-2 paradigm valtas/eltolodas, de nem mondanam hogy nem tudjak hogy mit akarnak.
amit en latok, az az, hogy van egy marhanagy teher rajtuk, hogy egyreszrol a felhasznalok legnagyobb tobbsege azt szeretne, hogy semmilyen visszafele nem kompatibilis valtozas ne tortenjen, emellett van egy nagyon hangos tomeg, akik viszont azt szeretne, hogy legyen toronyora lanccal, jellemzoen valamilyen mas "trendibb" programozasi nyelv felol erkeuve.
ekozben egy nagyon pici aktiv fejlesztoi mag viszi a projectet, akik tobbnyire konzervativok a valtozassal szemben, es gyakorlatilag a core fejleszto es az atlag php fejleszto szinte semmilyen forumon nem talalkozik egymassal, ezert a kozvetlenul csak a framework fejlesztok, meg az ifju lelkes java titanok iranyabol erkezik feedback.

Dönthettek, hogy bevezetik a típusellenőrzést vagy sem, nem tudták eldönteni, így született a mostani köztes megoldás, ami minden, csak nem jó.

utolag visszatekintve nem biztos, hogy a legjobb megoldas volt a jelenlegi typehintek bevezetese, de szerintem nem annyira veszes.
ha belegondolsz a php sosem tamogatta az objectek kozotti type juggling-ot, ezert onmagaban az nem lenne problemas(bar az array typehintnel mar inog egy picit a lec).

Ez olyan, hogy vagy megcsinálom rendesen, vagy sehogy...

egyetertek, szerintem is az a nagyobb problema, hogy ezzel a felmegoldassal kinyitottak pandora szelencejet, mivel azotta folyamatosan felmerulo igeny, hogy de a scalar tipusokra miert nem tamogatott.
utolag en azt gondolom, hogy az lett volna a jo megoldas, hogy csak akkor kerulhet be a nyelvbe a typehint, hogy ha mar ki van dolgozva a koncepcio az osszes tipusra.

(Egyébként ez a káosz érződik az egész nyelvben, nem csak a típusellenőrzésnél, de ez az én véleményem...)

igen, nekem is sokszor az a velemenyem, hogy a kevesebb munkaval jaro megoldast kerul megoldasra, ami legtobbszor nem a legjobb, vagy tuneti kezeles.
ez volt a namespace-ek kapcsan (egyreszt ugye ezert lett a \ a separator, mert egyebkent a buta parser nem tudta volna feloldani a ketertelmuseget, illetve ezert lettek a namespace-ek a jelenlegi formajukban implementalva, aminek a kovetkezmenye az, hogy nem tudsz egy nevterbol mindent exportalni, mert igazabol a nevter nem is egy plusz absztrakcios szintkent van a core-ban implementalva, csak elso ranezesre tunik ugy.

Thread-re nincs szükség a PHP-ban, ha csak weblap generálásra használod, amire a nyelv amúgy hivatott... Miért is kéne mindent exception-re alakítani?

ezek meg a gyakori "hyped" otletek/igenyek a mas nyelvekbol erkezo fejlesztok iranyabol.
itt lehet csemegezni a jobbnal jobb otletek kozul, es ezt az emberek komolyan is gondoljak (najo, kiveve talan Chuck Norrist).

ps: pont most olvasok egy slide-ot, ahol Johannes (az 5.3 kiadasmenedzsere) egesz jol elmagyarazza hogy miert nem erdemes eroltetni a referenciak hasznalatat:

Tyrael
29

innentol kezdve a

inf · 2012. Már. 3. (Szo), 22.12
innentol kezdve a referenciakkal valo jatszadozassal nem igazan lehet memoriat sporolni az esetek 99%-ban.

Nekem volt olyan eset, amikor a referenciakénti átadással (lehet, hogy memóriát nem), de sebességet sikerült növelnem. Már nem emlékszem pontosan a kódra, csak arra, hogy egy nagyon nagy stringet adtam át benne referenciaként. Mondjuk szerencsésebb, ha egy példányváltozóba rakod bele az adott stringet, és úgy tud utazni a metódusok között, ilyen átadások nélkül. Mai fejjel már biztosan így oldanám meg. A tömböknél csak arra akartam utalni, hogy nekem sok esetben az eredeti tömb módosítására lenne szükségem, amit meg nem lehet úgy megoldani, ha csak egy másolatot kapok. Persze sok esetben meg a másolat is elég, ha mondjuk adatbázis sorokat dolgozol fel...

az $appender->append($foo=array()); nyilvan mukodne.

Persze, csak előbb törném el a kezeimet, mint hogy ilyet leírjak...

ebben a peldadban nincs setter, az eredeti postodban arrol beszeltel:

    class MyTest {  
        public function helloWorld() {  
            echo('Hello world!');  
        }  
    }  
      
    class Example {  
        protected MyTest $test;  
          
        public function setTest($test) {  
            $this->test = $test;  
        }  
          
        public function void doSomething() {  
            $this->test->helloWorld();  
        }  
    }
Parancsolj. Nem hiszem, hogy ezt akkora probléma lett volna elképzelni. Én egyébként azzal is kibékülnék, ha commentbe betehetném a példányváltozók típusát, és onnan olvasná ki a netbeans, ha már a php nem alkalmas ilyesmire. A lényeg itt csak annyi volt, hogy örülnék neki, ha menne az automatikus kiegészítés minden esetben.

ha kiszedem a constructort, akkor a kovetkezo docblock szinten mukodik nalam:
/**
* @property MyTest $test
*/

Na én is valami ilyesmire gondoltam, nem tudom, hogy netbeans-ben van e lehetőség rá...

egyreszrol a felhasznalok legnagyobb tobbsege azt szeretne, hogy semmilyen visszafele nem kompatibilis valtozas ne tortenjen

Én ezt a hozzáállást nehezen tudom megérteni. Ha vannak unit test-jeid egy rendszerhez, akkor pillanatok alatt kidobják, hogy mi az, ami az új PHP verzióval nem megy, és tudod javítani. (Gondolom az említett fejlesztőknek nincsenek unit testjeik.) A másik meg, hogy ha nem kompatibilis a kódjuk az újabb verzióval, akkor ne váltsanak át rá. Sok szolgáltatónál már most is lehet php verziót választani, egyáltalán nem kötelező váltani... (Legalábbis azonnal biztosan nem.)

ezert onmagaban az nem lenne problemas(bar az array typehintnel mar inog egy picit a lec).

Pontosan az array, ami kiverte nálam a biztosítékot, mert ha azt mondják, hogy csak az objektumokra működik a type hint, akkor azt elfogadom, de akkor minek vették bele az array-t? És ha már az array-t bevették, akkor a többi típust miért nem? Szerintem sokkal jobban át kellene gondolniuk minden ilyen lépést mielőtt bevezetnék.
30

A lényeg itt csak annyi volt,

Poetro · 2012. Már. 3. (Szo), 22.20
A lényeg itt csak annyi volt, hogy örülnék neki, ha menne az automatikus kiegészítés minden esetben.

Lehet van másik szerkesztő, ami alkalmasabb erre, mint a NetBeans. Eleve a PHP IDE-ből van legalább egy fél tucat használható, talán érdemes lenne velük kísérletezni. Lehet valamelyik tudja azt a szolgáltatást, amire neked szükséged van. Vagy ha nem, akkor is írhatsz a NetBeans alá egy kiegészítőt, ami megvalósítja ezt neked.
32

Egyelőre nem volt időm

inf · 2012. Már. 3. (Szo), 22.27
Egyelőre nem volt időm megismerkedni több ilyen rendszerrel, plugin-t viszont mindenképp írok nb-hez, már vannak ötleteim, csak jobban utána kell néznem a témának.
36

probald mar ki pls. lusta

Tyrael · 2012. Már. 4. (V), 01.58
probald mar ki pls. lusta vagyok felrakni emiatt a netbeans, de latatlanban egy sor ra merek tenni, hogy van benne docblock tamogatas, es nalad is menne a commenttel amit irtam feljebb.

szerk: targytalan, latom lejebb, hogy sikerult megoldani.

Tyrael
31

Közben utánanéztem,

inf · 2012. Már. 3. (Szo), 22.24
Közben utánanéztem, netbeans-ben ez a megoldás az automatikus kiegészítésnél a típus megadására:

class MyTest {

    public function helloWorld() {
        echo('Hello world!');
    }

}

class Example {

    /** @var MyTest */
    protected $test;

    public function setTest(MyTest $test) {
        $this->test = $test;
    }

    public function doSomething() {
        $this->test->helloWorld();
    }

}
Fontos, hogy két csillag legyen a @ előtt, csak úgy működik.
(Majd utánanézek annak is, hogy a visszatérő értékekkel mit lehet kezdeni...)
41

annotációk

Crystal · 2012. Már. 5. (H), 14.04
hello,

a netbeans a következőket is kezeli:

@return <típus>
@param <típus> $paraméternév (így a metóduson belül lesz a paraméterre autocompletion)

ill. osztályokat még a következőkkel lehet annotálni:
@method <metódusnév> (ha __call() -lal implementálod)
@property <attribútumnév> (ha __get() __set() -tel implementálod)
@property-read <attribútumnév> (ha csak __get() van)

A /** -nél a két csillag azért kell, mert a javadoc is így működik, és ezért ez láthatóan konvenció lett.
43

Én ezt találtam a témában, a

inf · 2012. Már. 5. (H), 20.51
Én ezt találtam a témában, a netbeans ettől egy kicsivel eltér, viszont a @ után az automatikus kiegészítés felajánl pár dolgot (sajnos nincs beépített leírás hozzájuk, mint mondjuk a függvényekhez).
40

nem biztos h olyan konnyu tesztekkel

blacksonic · 2012. Már. 5. (H), 13.19
Én ezt a hozzáállást nehezen tudom megérteni. Ha vannak unit test-jeid egy rendszerhez, akkor pillanatok alatt kidobják, hogy mi az, ami az új PHP verzióval nem megy, és tudod javítani. (Gondolom az említett fejlesztőknek nincsenek unit testjeik.) A másik meg, hogy ha nem kompatibilis a kódjuk az újabb verzióval, akkor ne váltsanak át rá. Sok szolgáltatónál már most is lehet php verziót választani, egyáltalán nem kötelező váltani... (Legalábbis azonnal biztosan nem.)


Meg ha vannak is tesztek a rendszerre, egy 10 eve fejlesztett es nap mint nap hasznalt programot nem kis effort atrakni egy visszafele nem kompatibilis frissitesnel...talan ez egy nagy erv lehet hogy agalnak ellene
42

Meg ha vannak is tesztek a

inf · 2012. Már. 5. (H), 20.50
Meg ha vannak is tesztek a rendszerre, egy 10 eve fejlesztett es nap mint nap hasznalt programot nem kis effort atrakni egy visszafele nem kompatibilis frissitesnel...talan ez egy nagy erv lehet hogy agalnak ellene

Senki sem mondta, hogy kötelező frissíteni...
44

Van, amikor nincs más

Hidvégi Gábor · 2012. Már. 6. (K), 00.16
Van, amikor nincs más választás, mert a régen használt verziót már nehézkes összeszedni a netről, főleg, ha több függősége is van. Nálunk pont most volt ilyen eset, rengeteg bosszúságot okozott (a jövőben jobban fogunk figyelni erre).
45

Értem.

inf · 2012. Már. 6. (K), 09.15
Értem.
46

ez igy van

blacksonic · 2012. Már. 6. (K), 17.49
csak arra celoztam h tesztekkel lefedett kodnal sem hiphop megy a dolog
47

Persze, de az új verziók sem

inf · 2012. Már. 7. (Sze), 00.21
Persze, de az új verziók sem hiphop jelennek meg, és terjednek el, szóval van idő átírni a kódot. A kérdés inkább csak az, hogy van e rá elég erőforrás, mert ingyen nem dolgozik senki...
48

Ez sosem szabad, hogy

hron84 · 2012. Már. 19. (H), 01.13
Ez sosem szabad, hogy kerdeskent felmeruljon. Ahol ez kerdeskent felmerul, ott mar az is gond, hogy kivettek a register_globals-t. A kod karbantartasara mindig kell idot szakitani, kulonben nem vallalhato ra _semmilyen_ garancia. Hosszu tavon a ceg szivja meg, ha nem allokal idot a karbantartasra.
35

ez by design ilyen, erteket

tgr · 2012. Már. 4. (V), 00.15
ez by design ilyen, erteket nem adhatsz at referenciakent, mivel a hivo kornyezetben az array()-t nem a rendeled hozza semilyen valtozohoz, ezert nem lesz mire hivatkoznod a referenciakent.
az $appender->append($foo=array()); nyilvan mukodne.


Csak nem úgy, ahogy várod.

function f(&$i) {
    $i++;
    echo $i;
}
f($i=1); // 2
echo $i; // 1
(Legalábbis újabb PHP verziókban, mert régebbiekben még mindkét echo 2-t adna.)

Nyilván ha csak dísznek kell az értékadás, hogy tudj tömbliterált tenni a függvényhívásba, akkor mindegy, de egyébként szépen példázza, mekkora katyvasz a referencia szerinti értékadás, teljesen ötletszerű, hogy mit tekint hibának és mit nem.
37

igen, a valaszodbol rajottem,

Tyrael · 2012. Már. 4. (V), 02.05
igen, a valaszodbol rajottem, hogy itt az tortenik, hogy az $i=1 et atadva az ertekadas visszateresi ertekere mutato referenciajat adjuk at a fuggvenynek, nem pedig az $i-re mutato referenciat.
($i=1 muvelet 1-gyel fog visszaterni (ezt adjuk at referenciakent), "mellekesen" pedig beallitja $i erteket 1-re.)

Tyrael
38

Igen, de ez teljesen

tgr · 2012. Már. 4. (V), 12.39
Igen, de ez teljesen inkonzisztens az összes többi művelettel, amire fatal errort dob, hogy kifejezést próbálsz átadni referenciaként. Kivéve a függvényhívást, ami megintcsak megengedett:

f(1); // Fatal error: Only variables can be passed by reference

function one() {
    return 1;
}
f(one()); // 2
Az inkrementálás még viccesebb:

$a = 1;
f(++$a); // 3
echo $a; // 2
f($a++); // Fatal error: Only variables can be passed by referencer
szóval a referenciák kezelése eléggé WTF-díjas rész a PHP-ben.
39

Á ugyan, jó ez :D Nálam is

inf · 2012. Már. 4. (V), 18.09
Á ugyan, jó ez :D
Nálam is megkapta az arany málnát, nem túl sűrűn használom...
10

Azért jó...

Gixx · 2012. Már. 2. (P), 17.28
...ha az ember virtuális szervert bérel, mert:

1. ő az úr a házban (legalábbis az egyik, ha többen állnak össze)
2. iszonyat gyors külföldre is
3. kb ugyanannyiba kerül mint egy magyar hosting, ahol folyton reklamálni kell minden feature-ért, itt viszont nem. A legkisebb csomag bőven elég két embernek, így fejenként csak 10 dodó egy évre. De ha fusi melókat tudsz/akarsz hostolni (20GB azért elég nagy hely), akkor még pénzt is tudsz keresni vele.
4. nem kell a fizikai vassal foglalkozni, fejleszteni, vinyót cserélni, ügyeletet tartani.
5. ha 3-4 innovatív hangulatú fejlesztő összeáll, akkor nem csak hogy még olcsóbb is lesz, hanem mindig mindenből fel lehet rakni a legfrissebb verziót is.

Én a Linode-nál vagyok közösen egy haverral. Ha ő is belemegy (mert miért ne), akkor felrakjuk az Apache 2.4-et és a PHP 5.4-et, mihelyst az Ubuntuba belekerülnek csomagként.

Aztán már csak a Zend Framework 2-nek kell végre célba érnie :)
16

@linode

joed · 2012. Már. 2. (P), 22.51
[off]
http://bitcoinmedia.com/compromised-linode-coins-stolen-from-slush-faucet-and-others/
[/off]
24

ez mi?

Gixx · 2012. Már. 3. (Szo), 10.47
This morning I received an emergency SMS notification that my pool’s bitcoin balance was low.


Milyen poolnak a bitcoin balansza alacsony? És ez mit jelent? Lehet, hogy én csinálok valamit rosszul, de ez nekem nem mond semmit...
28

bitcoin megvan? ha nem, akkor

Tyrael · 2012. Már. 3. (Szo), 17.09
bitcoin megvan?
ha nem, akkor lasd wikipedia
roviden: futtatsz egy progit, general szepen lassan egy virtualis valutat, amire van egy elosztott rendszer hogy anonym modon tudj penzt mozgatni.
ezt a virtualis valutat tobbfele modon penze tudod tenni, a forgalomban levo mennyiseg alapjan alakul az arfolyam.
a blogpost iroja egy olyan clusternek/poolnak az uzemeltetoje, ahova mas "banyaszok" is be tudnak tarsulni.
a hir arrol szol, hogy tegnap tobb ilyen bitcoin banyat is feltortek, es atutaltak az ott levo mozdithato vagyont, es a nyomok alapjan nem a vps-t tortek fel, vagy a rajta futtatott szoftverek valamelyiket, hanem a tamadok a linode admin paneljen keresztul leptek be, modositottak root jelszot, leptek be a szerverre, es utaltak el a penzt.
ugyan a tamadas csak egy celzott kis csoportot erintett (ahol az eddigi hirek alapjan a poolok uzemeltetoje mindenhol benyelte az okozott veszteseget, es nem terhelte at ezt a tagokra), de amennyiben bebizonyosodik, hogy a linode adminja a lyukas, az elegge kellemetlenul erinthet minden linode felhasznalot.
roviden kb. ennyi a hir ide vonatkozo resze.

Tyrael
20

+1 a linodera (bar a mai

Tyrael · 2012. Már. 3. (Szo), 00.01
+1 a linodera (bar a mai hirek kicsit engem is aggasztanak).
dotdeb repobol mar most is felrakhatod az 5.4-et, de ahogy irtam mar, en meg varnek vele kicsit (legalabb amig az apc-s crash problemakat javitjak)

Tyrael
25

Speed test

dropout · 2012. Már. 3. (Szo), 11.47
Egy kis teszt eredmény a Teljesítmény bekezdéshez: http://news.php.net/php.internals/57760