ugrás a tartalomhoz

PHP 6 Unicode támogatással

Hojtsy Gábor · 2005. Aug. 11. (Cs), 19.04
A mai napon kaptam el egy levelet, amelynek köszönhetően a fő fejlesztési ág és a PHP 5.1 kettéválasztásáról értesültem, és az is nyilvánvalóvá vált, hogy a PHP 6 előkészítése kezdődött meg a fő fejlesztői ágon. Ezzel félretehetjük a nagy léptékű találgatásokat, amelyek a PHP 6 Parrot alapú megvalósításáról szóltak. Az mindenesetre figyelemreméltó, hogy az előkészített Unicode változások még közelebb hozzák a PHP-t a Parrot motorhoz.
Akármennyire sikeresnek is bizonyult a PHP az utóbbi években, ez az egyetlen nyelv a P-hármas (Perl, Python, PHP) közül, mely nem túl okosan figyelmen kívül hagyta azt a többnyelvű és több nemzetiségű környezetet, melyben működik. A szoftverfejlesztő közösség a Unicode támogatás megvalósítása felé halad már jó ideje, és a PHP nem engedheti meg magának, hogy kimaradjon ebből a folyamatból.
Így kezdődik az angol nyelvű PHP Unicode support design document, melyet Andrei Zmievski küldött el tegnap a fejlesztői listára, értesítve a PHP készítőit a várható változásokról. A dokumentum részletesen ismerteti a Unicode támogatás bevezetésének lépéseit, a meglévő PHP függvényekre és módszerekre gyakorolt hatását.

Az egyik legfontosabb dolog, hogy a nagy verzióugrás ellenére (legalábbis a Unicode támogatást illetően) törekedni fognak a visszafelé kompatibilitásra, a korábbi módszerek használhatóságára, bár a teljesítmény terén valószínűleg áldozatokat kell majd hozni. A másik jó hír, hogy az ICU (International Components for Unicode) kódkönyvtár felhasználásával fogják megvalósítani a támogatást, ezzel egy már bizonyított alapot felhasználva, felgyorsítva a fejlesztést.

Andrei ma éjjel küldött figyelmeztetést a fejlesztői listára, hogy a Unicode támogatás első fázisának beépítését elkezdi. Bár ennek nyomát még nem látni a verziókezelő rendszerben, feltehetően hamarosan megkezdődik, hogy a további fejlesztések folytatódhassanak, a tesztelés megkezdődhessen.

Mindezek természetesen csak előzetes információk, mivel a PHP 6 kódjának karbantartása hivatalosan csak néhány órája kezdődött meg, nem pontosan ezt kell elvárni a végleges kiadástól, melyre legalábbis hónapokat, ha nem éveket kell várnunk.
 
1

mi lehet még

Kérésre törölve 10. · 2005. Aug. 12. (P), 13.53
Érdekelne, hogy milyen újdonságokat tudnak még beletenni a 6. verzióba (a még nagyobb OO támogatás mellet). Szerintem a PHP 4 (esetleg 5) már így is "tökéletes".
2

Hah :)

Bártházi András · 2005. Aug. 13. (Szo), 00.17
A PHP jelenlegi Unicode támogatása... nos, inkább nem nyilatkozom. :) És lenne még mit javítani a nyelven magán is. Vagy ha nem is továbbfejleszteni és új dolgokat bevezetni - mert tudtommal az a szándék, hogy viszonylag egyszerűnek tartsák meg -, akkor a jelenlegin egy kicsit pofozni. Sajnos a PHP az egy közel sem tökéletes nyelv. :(

-boogie-
3

Mire gondolsz?

Hodicska Gergely · 2005. Aug. 13. (Szo), 12.21
Szia!

a jelenlegin egy kicsit pofozni. Sajnos a PHP az egy közel sem tökéletes nyelv
Mint nyelv, mi az ami hiányzik belőle?

Nekem pl. a namespace, azt tényleg nem értem, hogy miért fáj nekik összehozni, bár ez már erősen alakulóban van.

Meg pár következetlenség zavar (pl.), néha érdekes levelezések mennek a belső fejlesztői listán.


Felhő
4

Változók

Bártházi András · 2005. Aug. 13. (Szo), 13.42
A változók jobb elérése. Múltkor azt volt (és még mindig az) a problémám, hogy nem tudtam egy olyan függvényt írni, mely változókat hoz létre az azt meghívó környezetben, vagy legalábbis úgy, hogy az onnan elérhető legyen. A globális változók nem globális változók, mert deklarálnod kell őket.

A reguláris kifejezések támogatása nem olyan rossz, de függvény szintről nyugodtan lehetne beépített nyelvi kifejezéssé tenni, mint az már olyan sok nyelvben így van (és sok nyelvben nem).

-boogie-
5

Basszus

Hodicska Gergely · 2005. Aug. 13. (Szo), 15.01
Múltkor azt volt (és még mindig az) a problémám

Pedig még példakódot is küldtem, és többször írtam, hogy nem így van, nyugodtan használhatod erre a $GLOBALS-t. :(

Kifejezetten a hívó függvény scope-jában létrehozni változót az elég ritka nyelvi lehetőség.

A regexp-et sajnos tuti nem fogják nyelvi elem szintre hozni. Ez a nyelvvel kapcsolatos filozófia része. Amúgy meg kifejezetten jó a regexp a PHP-ben.


Felhő
6

OFF

Bártházi András · 2005. Aug. 13. (Szo), 15.07
Ami a példakódot illeti, a többi hozzászólásomat, hogy ez amit írtál miért nem jó, azt nem olvastad el.

Nem is a hívó függvény scope-jában akarok létrehozni, hanem azt szeretném, hogy ahol létrehozom, a hívóból elérhető legyen. Ez csak akkor megvalósítható, hogy ha leírom, hogy global $valtozo, vagy ha a hívó kód a program "gyökerében van", vagy használom a GLOBALS tömböt. Ezek egyike sem használható megoldás. Zárjuk le ezt a témát, nem ide való.

-boogie-
7

OFF - nem én hoztam fel

Hodicska Gergely · 2005. Aug. 13. (Szo), 15.35
Tőlem lezárhatjuk, nem az én próblémám.

Ami a példakódot illeti, a többi hozzászólásomat, hogy ez amit írtál miért nem jó, azt nem olvastad el.

Érdekesen emlékszel a dolgokra, Te írtad ezt: http://weblabor.hu/levlistak/wl-phplista/2005/07/045808. Ebből az derült ki, hogy azért nem jó a $GLOBALS, mert úgy tudtad, hogy kell még külön globals kulcsszó is, de nem kell kitenni, ráadásul a problémára amit írtál teljesen jó megoldás.

A globális változók nem globális változók, mert deklarálnod kell őket.

Ez nem így van, legalábbis PHP esetében.


Felhő
19

ésígy?

bbalint · 2005. Aug. 15. (H), 10.51

<script language="PHP">
  function változókat_csináló(&$scope){
    // itt valamilyen viselkedés kell, ilyesmi, pl:
    $scope['hónap'] = date('n');
    if($scope['hónap'] == 1)
      $scope['január'] = 1;
    if(0)
      $scope[0] = 0;
  }
  
  változókat_csináló($tömb = array()); extract($tömb, EXTR_OVERWRITE);
  
  print_r(get_defined_vars());
  
  function akármi(){
    változókat_csináló($tömb = array()); extract($tömb, EXTR_OVERWRITE);
    
    print_r(get_defined_vars());
  }
  akármi();
</script>
szóval, amit írtál, olyant tényleg nem lehet csinálni, de valami hasonlót igen:
a másik változónév-térben levő függvényben, akármicsodában létrehozol egy tömböt, és abba pakolsz változókat, majd azt a tömböt kicsomagolod/kezeled az eredetiben.

(szvsz) én is őrülnék, ha az [előző] EG(active_symbol_tablé)-t el lehetne érni mindig valamely függvényen keresztül ...

bbalint
20

extract nem jó ide

Hodicska Gergely · 2005. Aug. 15. (H), 12.27
Szia!

This function is used to import variables from an array into the current symbol table.


Felhő
22

hát

bbalint · 2005. Aug. 15. (H), 12.44
András eszonta:
problémám, hogy nem tudtam egy olyan függvényt írni, mely változókat hoz létre az azt meghívó környezetben
én erre a dologra igyekeztem valami megoldást adni; ami nem a legjobb, az biztos ...
én olyan kódot írtam oda le, ami nem hoz létre a meghívó környezetben változókat, de azt megteszi helyette az extract()

bbalint
24

Köszönöm

Bártházi András · 2005. Aug. 15. (H), 22.02
Köszönöm, végül magánban anno egy hasonlót javasoltak nekem. Sajnos ezt sem tartom igazi megoldásnak - a saját Perl környezetemben rövidebbhez szoktam. Jelenleg maradt az, hogy a függvényt csak a program "gyökeréből" hívjuk, de nem az igazi. De ezt egy másik topicban.

-boogie-
8

PHP6 - tavaszi nagy takarítás

Hodicska Gergely · 2005. Aug. 13. (Szo), 15.57
Közben úgy tűnik, hogy mégsem törekednek majd annyira a kompatibilitásra, sőt lehet, hogy ezt a verziót arra is felfogják használni, hogy jó sok elavult, vagy nem túl szerencsés dolgot kivágjanak a PHP-ből. Legalábbis erre utal Rasmus Lerdorf tegnapi levele a belső fejlesztői listán: http://news.php.net/php.internals/17883. A kezdeményezés, úgy tűnik, a többi fejlesztő támogatását is élvezi. Személy szerint én örülök ennek, talán már korábban meg kellett volna lépni. Ezek a "feature"-ök szinte minden PHP-t ért támadásban a lista elején vannak, és hát valjuk be őszintén túl sok értelmük nincs.


Felhő
14

$_MEMORY

Hodicska Gergely · 2005. Aug. 14. (V), 11.39
Sziasztok!


Épp most jött egy nagyon király ötlet a 6-os verzióval kapcsolatban:
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.
Rasmus vitaindító levelében szerepelt, hogy illene a 6-osba belepakolni egy opcode cachet is. (mondjuk itt érdekes, hogy a zend-es fiúk mit szólnak majd hozzá, mert azért ez némileg érvágás lehet. Főleg ha az eaccelerator kerülne bele. ;)) Jelenleg az volt a felvetés, hogy az APC szinte teljesen kész arra, hogy bekerülhessen (főleg akkor emiatt még kicsit tuningolnák). Az APC-nek pedig van egy olyan kevésbé ismert funkciója, hogy lehet benne egyszerűen tárolni memóriában tetszőleges változót. Ez a kérések között is permanens maradna. És ennek használatát egyszerűsítené le az újonnan tervezett tömb.

+1


Felhő
23

nem hoz osztatlan örömöket

Hojtsy Gábor · 2005. Aug. 15. (H), 21.34
A legtöbb fejlesztői blogban óvatosságra intenek a fejlesztők, én nem látom lehetőségét most, hogy ezek a változások keresztül menjenek, nem kellene ezeket tényként kezelni.
9

még 5 sincs...

Dualon · 2005. Aug. 13. (Szo), 19.00
Nagyon örülök, hogy fejlődik a PHP, de még mindig egy csomószor abba ütközöm, hogy a szolgáltatók 4.x verziót használnak. A váltást firtató kérdésemre a válasz a "majd ha kiforrott/biztonságos lesz" különböző variációi szoktak lenni. Egyszóval meglehetősen előremutató ez a hír. :)
Ha belefér a témába: Miért? Mi az, ami egy stabil 5-ös változatban nem kiforrott, nem biztonságos? (Erre nem szoktam választ kapni.)
10

<Nincs cím>

attlad · 2005. Aug. 13. (Szo), 19.06
Pl. nincs belőle hivatalos debian csomag :-) (vagy van?)

Attila
11

az nincs...

connor · 2005. Aug. 14. (V), 01.26
De szerintem a legjobb, ha fordítasz sajátot. :)

--
connor
12

Pont fordítva

Bártházi András · 2005. Aug. 14. (V), 11.17
Nem tudom, nálam pont fordítva áll a helyzet. Egyik ügyfél sem kérte még, pedig lenne... :)

A jelek különben azt mutatják, hogy a PHP 5.0 ki fog maradni a legtöbb indián életéből, a cégek egyből 5.1-re fognak áttérni. Érdekes módon ez a MySQL-nél is hasonló, sokan még mindig 4.0-t használnak, pedig a 4.1 már stabil, s hamarosan itt van az 5.0 is. Arról van szó, hogy nincs olyan ütős alkalmazás, mely megkövetelné ezen verziókat, a PHP 5.0 OO képességei, vagy a MySQL 4.1 beágyazott SELECT-je nélkül is úgy tűnik, hogy jól elvannak az emberek.

SZVSZ belefér: szerintem a szolgáltatók nem szeretnék megbolygatni a konfiguráiójukat, amíg nem kell, illetve könnyen előfordulhat, hogy PHP 5.0 alatt nem fog egy PHP 4.x alkalmazás futni, s ha váltanak, akkor ez kényelmetlenséget jelenthet az ügyfeleknek. Pedig nem nehéz megoldani, hogy a kettő egymás mellett fusson. Nem hinném, hogy a PHP 5 biztonságban vagy hibák tekintetében nagyobb problémát jelentene, mint a PHP 4.x.

-boogie-
15

Fejlesztői szokások

Hodicska Gergely · 2005. Aug. 14. (V), 11.52
Szia!
Nem tudom, nálam pont fordítva áll a helyzet. Egyik ügyfél sem kérte még, pedig lenne... :)
Ahogy én látom inkább az a jellezmő, hogy a legtöbb ügyfélnek nincs közvetlen elképzelése, hogy milyen környezetben készüljön az alakalmazás. Legtöbb esetben mi mondju meg, hogy milyen DB, egyáltalán milyen nyelven készüljön...
Arról van szó, hogy nincs olyan ütős alkalmazás, mely megkövetelné ezen verziókat, a PHP 5.0 OO képességei, vagy a MySQL 4.1 beágyazott SELECT-je nélkül is úgy tűnik, hogy jól elvannak az emberek
...és itt már inkább az a döntő, hogy adott cégnél milyen eszközök, kiforrott megoldások vannak. És inkább ezek szempontjából nehéz az átállás. Ugye PHP esetén nem annyira jellemző az OOP eröltetése, ezért nem hiányzik annyira a PHP5 (pedig mennyi jóság van még benne); aki MySQL-en nőtt fel, annak nem hiányzik a subselect, meg társai, jól el van nélküle is. Pedig ezek mind nagyon hatékony eszközök, csak egy bejáratott ügymenet esetén nehéz az átállás, mert sok előregyártott elem/eszköz nem áll még rendelkezésre ebben a környezetben.


Felhő
16

OO

saxus · 2005. Aug. 14. (V), 14.34
"PHP 5.0 OO képességei"

Soha nem értettem, hogy miért erőltetik mindenáron egy alapvetően lineáirs szkriptnyelvben az OOP-t ennyire. Multkor kaptam egy webshop motort javításra és befejezésre, az egész OOP-n alapult. De nem sok értelmét láttam annak, hogy egyes "rendszerszintű" függvényeket átemeljenek egy külön objektumba. És annak sem, hogy a modulok is egy-egy objektumot alkossanak. Csak felesleges pluszmunkának, és felesleges kódtöbbletnek láttam.

Természetesen van, amire nagyon is jól használható, és sokat segítenek, (például SQL réteg, mintarendszer, Mailer, stb.) de hogy mindenhova azt használjunk, azt feleslegesnek érzem. Csak növeli a munkát azzal, hogy mindenhova beírjuk a szükséges részleteket, illetve mindenhova írogathatjuk a $this -szeket, mikor bőven megoldható lenne nélküle is.

Szóval szerintem ezért nem igénylik annyira a PHP5 fejlett OOP képességeit.

Másrészt nagyon nincs is, ami kihasználná, igaz ebbe beletartozik az is, hogy nem feltétlen éri meg nagyon rá fejleszteni, mert nem terjedt el. Ördögi kör.
17

OO, lásd Ruby

Bártházi András · 2005. Aug. 14. (V), 16.59
A teljes Ruby on Rails az objektum orientáltságra épít, tehát SZVSZ van mire használni az OOP-t a web programozásban. :)

-boogie-
18

<Nincs cím>

saxus · 2005. Aug. 15. (H), 00.11
Lehet, hogy abban van, de részemről maradok a - számomra - jól bevált hibrid módszernél, ameddig meg nem győződök arról, hogy máshogy jobb.
21

rossz a szemléletmód

Hodicska Gergely · 2005. Aug. 15. (H), 12.36
Szia!


Az OOP nem nyelvfüggő, hanem szemléletmód. Ezenkívül lényegesen növeli a kód újrahasznosíthatóságát. (Lehet, hogy erről össze is dobok egy cikket, mert visszatérő probléma.) De önmagában nem egy csodafegyver. És az hogy használod, attól még nem lesz feltétlenül jobb neked, de ha képes vagy jól használni, akkor nagy segítég lehet.
Multkor kaptam egy webshop motort javításra és befejezésre, az egész OOP-n alapult. De nem sok értelmét láttam annak, hogy egyes "rendszerszintű" függvényeket átemeljenek egy külön objektumba.
Ez nem OOP. Egyszerűen függvényeket bezártak egy objektumba, nem sokkal több, mintha egyszerűen egy fájlba tennéd őket.

Az OOP ott kezdődik, hogy megtervezed az objektumokat, és úgy, hogy ezeket szépen tudd kombinálni. Nem böszme objekumokat gyártassz, amik így végül abszolút speciális célra használhatóak, hanem apró építőelmeket, amikt aztán tudsz megfelelően kombinálni. És akkor nyersz is vele mind a kód rugalmasságában, a kód karbantartatóságában és nem kevésbé fontos, hogy időben.


Felhő
13

van az :-)

Hodicska Gergely · 2005. Aug. 14. (V), 11.28
Szia!


Működik pedig az szépen. Pl. az exit.hu már 5-ös PHP-val készült. Amúgy kísérlet képpen meg lehet nézni, hogy a belső fejlesztői listára érkező még nyitott bugokat összefoglaló listát összevetni a 4-es és az 5-ös verzió esetében. Mennyi, milyen?


Felhő
25

FÜggvénykészlet-bővülés

Anonymous · 2005. Aug. 20. (Szo), 18.04
Szerintem a phpnak óriási függvénykészlete van jelentleg is a többihez képest, de még kellene többet.
Sokat könnyítene a fejlesztés sebességén. Amikor scriptet írok phpben akkor is nyitva van egy ablak, amiben a php.net oldal function referencet bámulom.
26

PHP5 és a MySQL 5

Sweetchack · 2005. Aug. 26. (P), 22.07
Tisztában vagyok vele hogy a MySQL 5 még csak béta verziós.
Probáltatok már PHP5-ből tárolt tárolt eljárást hívni?
CREATE PROCEDURE valami()
BEGIN
SELECT * FROM valahonnan;
END;

mysql_query('CALL valami();');
Az a helyzet hogy a lekérdezés hibaüzenet nélkül lefut, viszont nincsen vissza adott rekordhalmaz.
Probáltam már mysqli_* -vel is, simán és objektum orientáltan, és PDO-val is.
Ez érdekes az égészben az az, hogy a JDBC-nek nem szóltak hogy a MySQL még csak béta, mert simán elérhető az eredmény.
Remélem a PHP5.1 fogja tudni.
JEdit-nek az SQL pluginjával és az "SQuirrel SQL Client" programokkal próbáltam.

Fentebb olvastam hogy az emberek milyen jól elvannak SubSelect nélkül. Én inkább dolgozok többet az adatbázison mint a PHP kódon.
27

Sok függvénynél is jobb a több :)

Sweetchack · 2005. Aug. 26. (P), 22.10
De konkrétan milyenre lenne szükséged? Mi volt az mit neked kellett megírnod, de úgy gondolod hogy jó lenne ha beépített függvény lenne?