ugrás a tartalomhoz

What's new in PHP6?

Anonymous · 2007. Május. 26. (Szo), 06.27
Nem lesz safe mode, de lesz Unicode
 ■
1

Is-is

janoszen · 2007. Május. 26. (Szo), 10.07
Vegyes érzésekkel várom PHP 6-ot. Egy részről dicséretes, hogy a Unicode support végre prioritást kapott, de sajnos akkor, amikor már elég sok mindenki fölkészítette a programját Unicode kezelésre. Szerintem, inkább konvertáló és adatfeldolgozó függvényekkel kellett volna bővíteni a palettát az egyetemes ki-be kapcsolgatás helyett. Ugyanúgy fogunk járni, mint a magic quotes-szal, hogy a programnak kell tudnia kezelni a Unicode dolgokat, nem a nyelvnek kell erre lehetőséget biztosítani. Főleg nem egy olyan HTTP-közeli nyelvnél, mint a PHP.

Amiket kiszednek (register_globals, magic_quotes, stb) az nagyon helyes, megfelelően idegesítő volt már így is.

64 bites integerekkel nem tudom, mit lehet kezdeni, hiszen aki ilyen méretű számokkal akar foglalkozni, az valószínűleg nem PHP-t fog használni. De azért legyen. Egy típussal több, amire föl kell készíteni a mindenféle függvényeket.

A goto ízlések és pofonok kérdése, én nem fogom használni annak ellenére sem, hogy nem lehet bárhova ugrani a kódban mégpedig azért, mert így könnyen kimaradhatnak egy-egy ciklus végéről a fontos lezáró részek. Kicsi hack-szagú.

A static binding szerintem, nagyon hasznos, lett volna már rá szükségem.

A hardened PHP patchet ugyan még nem próbáltam de hasznosnak hangzik.

A többi meg... megint csak ízlések és pofonok.

Összegezve, szerintem többségében jó lesz, úgyhogy alig várom.
7

re: Is-is

Hodicska Gergely · 2007. Május. 29. (K), 12.33
Egy részről dicséretes, hogy a Unicode support végre prioritást kapott, de sajnos akkor, amikor már elég sok mindenki fölkészítette a programját Unicode kezelésre. Szerintem, inkább konvertáló és adatfeldolgozó függvényekkel kellett volna bővíteni a palettát az egyetemes ki-be kapcsolgatás helyett. Ugyanúgy fogunk járni, mint a magic quotes-szal, hogy a programnak kell tudnia kezelni a Unicode dolgokat, nem a nyelvnek kell erre lehetőséget biztosítani.
Kérdés, hogy sokan mennyire jól csinálták meg az Unicode szövegek kezelését, ebből a szempontból nem rossz, hogy maga nyelv fogja automatikusan jól kezelni. Szerintem a többség egy csomó problémás aprósággal nincs tisztában. Plusz valószínűleg az ICU által nyújtott lehetőségek túlmutatnak a különböző extensionök funkcióin. Az viszont szerintem is érdekes lehet, hogy ha valaki általános keretrendszert szeretne mondjuk írni, vagy valami hasonlót, akkor kb. ifezgetnie kell, vagy elfedni ezt valamiylen osztállyal. Majd kiderül, hogy ezzel kapcsolatban merre fejlődnek a dolgok.

64 bites integerekkel nem tudom, mit lehet kezdeni, hiszen aki ilyen méretű számokkal akar foglalkozni, az valószínűleg nem PHP-t fog használni.
Hát elég sok mindent lehet kezdeni. ;) Pl.: http://www.mysqlperformanceblog.com/2007/03/27/integers-in-php-running-with-scissors-and-portability, itt a kommenteknél olvashatsz pár cifraságot. De pl. mi használunk egy lekérdezés optimalizálására egyfajta bit maszkot, ott is gond volt abból, hogy nem tudsz 2 31. hatványa fölé menni egy integer esetén, és csak trükkös módon tudsz nagyobb számot előállítani, amire meg szükséged lehet, mert simán lehet biginted az adatbázisban.

A goto ízlések és pofonok kérdése, én nem fogom használni annak ellenére sem, hogy nem lehet bárhova ugrani a kódban mégpedig azért, mert így könnyen kimaradhatnak egy-egy ciklus végéről a fontos lezáró részek. Kicsi hack-szagú.
Ezt igazából pont ilyen célra is szánják, parserek esetén lehet hasznos, teljesítmény növelő eszköz.

A static binding szerintem, nagyon hasznos, lett volna már rá szükségem.
Ez tényleg jó, hogy végre rendbetették. Hol volt rá szükséged?


Szerintem is előremutatóak a változtatások, csak jó lenne, ha kicsit jobban tesztelnék az új funkciókat, ne legyen az, hogy a bevezetés után visszajelzések alapján még kicsit játszadoznk, azzal, hogy mi hogy működjön.


Üdv,
Felhő
8

Válasz. :)

janoszen · 2007. Május. 29. (K), 15.45
Nem tudom, tartok tőle, hogy a Unicode support kicsit olyan lesz, mint a magic quotes... majd meglátjuk. :)

A 64 bites intek... nem tudom, ha ilyen dolgokat csinálnék, akkor valszeg extension írnék hozzá, de végülis jó hogy beletették.

.. static binding: azt hiszem, statikus metódusok kellettek. Nem kartam mindenhol példányosítani az osztály, mert gyakorlatilag egy toolkit osztály volt. :)
9

néha azért macerás ezt kitölteni

Hodicska Gergely · 2007. Május. 30. (Sze), 01.11
A 64 bites intek... nem tudom, ha ilyen dolgokat csinálnék, akkor valszeg extension írnék hozzá, de végülis jó hogy beletették.
Írnál egy extensiont kettő hatványainak össze éseléséhez? ;)

Nem kartam mindenhol példányosítani az osztály, mert gyakorlatilag egy toolkit osztály volt. :)
Ezt eddig is bármikor megtehetted még PHP4-ben is. Ez a módosítás másról szól: próbáld ki az alábbi példát:
<?php
class A
{
    static function foo()
    {
        self::bar();
    } 
      
    static function bar()
    {
        echo "A::bar";
    } 
} 
  
class B extends A 
{ 
    static function bar()
    { 
        echo "B::bar";
    } 
} 

B::foo();
?>
Intuitív módon az ember azt várná, hogy ez "B::bar" szöveget jeleníti meg, de nem. Na most PHP6-ban a static::bar() hívás hatására már ez a szöveg fog megjelenni.


Üdv,
Felhő
10

bitmask

Táskai Zsolt · 2007. Május. 30. (Sze), 07.01
hát nem tudom... ez a bitmaskos kérdés azért zavar engem. én ma már felnőttebb megoldásnak gondolnám egy osztályban jelölgetni a biteket, ami log(n)/32 darab intben tárolja, vagy ahogy épp hatékony. vagy ennyire hatékonyságra kihegyezett kód kellett, hogy ez az osztály sem fért bele? vagy nem értem(?).
11

lekérdezés!

Hodicska Gergely · 2007. Május. 30. (Sze), 08.49
Hogyan használod ezt az osztályt egy lekérdezésben? ;)
Itt adszerverekről volt szó, ahol olyan 100 milliós nagyságrendű hit van.



Üdv,
Felhő
12

extension

janoszen · 2007. Május. 30. (Sze), 08.58
Na látod, pont ezért kéne extension. Az nagyságrendekkel gyorsabb lesz. :)
15

az éselés? :/

Hodicska Gergely · 2007. Május. 30. (Sze), 14.54
Miért lenne gyorsabb számok összeéselése egy extensiönben? Ez kb. a nyelv esetén is C kód végzi, egy extensiön esetén meg még ott vannak járulékos tenni valók.


Üdv,
Felhő
16

Nem az éselést

janoszen · 2007. Május. 30. (Sze), 23.19
Nem az éselést csinálnám extben, hanem az egész feladatot, amit ez hivatott ellátni. :)
17

ez az egész feladat

Hodicska Gergely · 2007. Május. 31. (Cs), 11.57
Utána már csak az összeállított értékkel kell egy queryt végrehajtani. Nem hiszem, hogy ezt szintén megérné extensiönbe pakolni. ;)


Üdv,
Felhő
14

ilyesmitől tartottam:)

Táskai Zsolt · 2007. Május. 30. (Sze), 11.31
nem élek már én sem álomvilágban, hogy mindig a legszebb megoldás mellett kardoskodjak...
13

Változó

janoszen · 2007. Május. 30. (Sze), 08.59
Valakinek volt problémája a változók elérésével, úgyhogy inkább nem is kisérleteztem vele, nem volt rá fölösleges energiám. ;) De köszi a felvillanyosítást.
2

Nagyon jó!

Fraki · 2007. Május. 26. (Szo), 15.59
Már csak a szintaxist kéne megreformálni... idegesítő például, hogy minden azonosító elé dollárjelet kell írni.
3

Sztem nem

janoszen · 2007. Május. 26. (Szo), 16.07
Szerintem nem, mert azonnal látod mi a változó és mi nem...
4

Dollár

vbence · 2007. Május. 26. (Szo), 17.20
Ez valahogy működik más nyelvekben is dollár nélkül :)
5

máshol is

bandi · 2007. Május. 27. (V), 10.59
Más nyelvekben is így van, nekem speciel tetszik, nagyon furcsa utána visszaállni.
6

Nekem tetszik

presidento · 2007. Május. 27. (V), 17.29
Szerintem is élvezetes tulajdonság, hogy dollárjeleket kell alkalmazni.
Például mostanában használtam ilyesmit:
foreach (Array(...) as $f) fwrite($$f,$myText);
18

nem ér meg annyit

Fraki · 2007. Jún. 2. (Szo), 22.35
Igen, a named variables elég érdekes játék. De szvsz nem ér meg annyit, hogy ne lehessen eval()-lal helyettesíteni.

A dollárral -- amellett, hogy teljesen feleslegesen kell begépelni, és nehézkes is -- még más baj is van: különválasztja a függvény-, osztály- és mezőneveket a többi változótípustól (már a tokenek szintjén). Pedig hát minden nyelvben (magában a php-ban is) ezek közt eléggé elmosódik a határ.

Ezek egy dologban mind közösek: azonosítók (tokenizációs értelemben beszélek). És a tokenizáció szintjén nem kéne az azonosítókat két csoportra bontani. Mi a különbség egy objektum mezője és egy "sima" változó között? Semmi, mégis fölöslegesen beléjük kavar a szintaxis.

Elég következetlenül néz ki például egy osztálydeklarációban ez:

class Pager {
  public $count;

  public function __construct($x) {
    $this->count = $x * 2;
}
Az is enyhén gáz, hogy nem lehet függvényeket újradeklarálni, persze csak ha dolláros változóba rakjuk őket.

És mind-mind a dollár miatt... fölösleges őskori kavarás ez...
19

már hogyne érne meg

Hodicska Gergely · 2007. Jún. 3. (V), 11.51
De szvsz nem ér meg annyit, hogy ne lehessen eval()-lal helyettesíteni.
Az egyik legjobb dolog a PHP-ban. Rengeteg dolgot lényegesen könnyebb így leprogramozni, mint más nyelvekben. Az eval-t meg erre használni elég rossz megoldás lenne, nem egy teljesítmény bajnok.

$this->count
Én pl. speciel szeretem ezt a formát, mert jól olvasható a kódban, hogy mi lokális változó, mi osztály változó.

Az is enyhén gáz, hogy nem lehet függvényeket újradeklarálni, persze csak ha dolláros változóba rakjuk őket.
Ezt hogy érted (és miért a dollár miatt)?


Üdv,
Felhő
20

re: megéri

Fraki · 2007. Jún. 3. (V), 19.35
Én pl. speciel szeretem ezt a formát, mert jól olvasható a kódban, hogy mi lokális változó, mi osztály változó.


Úgy is elég jól látható, hogy this.count, nem?

Megpróbáltam utánanézni, állítólag a perlből van átvéve a dollározás; meg ha általában szintaxisról van szó, akkor azzal szokták védeni a php-t, hogy nem metaprogramozásra lett kitalálva. És mondjuk template-elés szempontjából tényleg előnyös, az idézőjeles stringben való behelyettesítést nagyon megkönnyíti. Ez valóban jó, nem kell megszakítani a stringet. Kíváncsi vagyok, a python és a ruby erre milyen lehetőségeket nyújt...

Ezt hogy érted (és miért a dollár miatt)?


A fv.-újradeklaráció php-ban tilos. Pedig ez hasznos dolog tudna lenni, például CMS-ek esetében, ahol felül lehetne írni default template-fv.-eket. Persze lehet változóba is függvényt tenni, de akkor megint keveredik a dolláros a nem dollárossal, egy számomra érdektelen különbséget mutatva, hogy az illető fv. újradeklarált vagy sem.