PHP 6 Unicode támogatással
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.Í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.
■ 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.
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.
mi lehet még
Hah :)
-boogie-
Mire gondolsz?
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ő
Változók
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-
Basszus
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ő
OFF
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-
OFF - nem én hoztam fel
É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.
Ez nem így van, legalábbis PHP esetében.
Felhő
ésígy?
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
extract nem jó ide
Felhő
hát
é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
Köszönöm
-boogie-
PHP6 - tavaszi nagy takarítás
Felhő
$_MEMORY
Épp most jött egy nagyon király ötlet a 6-os verzióval kapcsolatban:
is pretty much $_MEMORY with a few tweaks.
+1
Felhő
nem hoz osztatlan örömöket
még 5 sincs...
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.)
<Nincs cím>
Attila
az nincs...
--
connor
Pont fordítva
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-
Fejlesztői szokások
Felhő
OO
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.
OO, lásd Ruby
-boogie-
<Nincs cím>
rossz a szemléletmód
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.
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ő
van az :-)
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ő
FÜggvénykészlet-bővülés
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.
PHP5 és a MySQL 5
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.
Sok függvénynél is jobb a több :)