Kód és adat együtt - most már PHP-ben is lehetséges
Ismét egy olyan újdonságról számolhatok be, ami a PHP 5.1-ben jelenik majd meg. Ezúttal Ilia Alshanetsky ismerteti az új lehetőséget, amelynek lényege, hogy a PHP szkriptünket a fájl befejezése előtt lezárhassuk úgy, hogy az azt követő adatokat a Zend motor már ne dolgozza fel, de elérhetőek legyenek számunkra a hagyományos fájlkezelő utasításokkal.
A technika teljesen egybecsomagolt szkriptek kialakításakor hasznos, és Perlben már régóta ismert. Ott a
A PHP 5.1-es megoldás úgy fest, hogy aIlia tájékoztatása szerint a több megabájtos adattartalom sem okoz majd gondot a feldolgozásnál, hiszen ezt a Zend Engine már nem dolgozza fel, így nem terheli a PHP memória korlátját. A
■ A technika teljesen egybecsomagolt szkriptek kialakításakor hasznos, és Perlben már régóta ismert. Ott a
__DATA__ jelölőt kell elhelyezni a fájlban, ami a Perl kód végét jelzi, és az ezt követő részt a main::DATA (azaz pontosabban csomagneve::DATA) fájlkezelőről olvashatjuk be.A PHP 5.1-es megoldás úgy fest, hogy a
__HALT_COMPILER() utasítást adjuk ki, és a szkript fájlból olvasva a __COMPILER_HALT_OFFSET__ pozíciótól kaphatjuk meg a lezárás utáni adathalmazt. Ez lehetővé teszi, hogy telepítő szkripteknél szükséges fájlokat (akár több megabájtnyi adatot) is a fájl végére fűzzünk, és egyetlen PHP állományként tegyük elérhetővé azt.
<?php
// A szkriptfájl megnyitása a HALT pozíciótól
echo file_get_contents(__FILE__, NULL, NULL, __COMPILER_HALT_OFFSET__);
?>
<?php __HALT_COMPILER();
ide bármi kerülhet, akár bináris adat is
file_get_contents() hívás természetesen már a memóriába emeli az adatokat, ezért itt legyünk körültekintőek, ha sok adatot kívánunk beemelni egyidőben.
Ronda
-boogie-
mindegy
__HALT_COMPILER__vagy__HALT_COMPILER()? Úgyse függvény, mint ahogy sok más nyelvi elem sem, ami annak látszik.nem mindegy
Ezen felül bár lehet, hogy konkrétan a fordítónak jelez, hogy itt fejezd be a fordítást, mint nyelvi elem, egyáltalán nem ez a feladata. Sokkal szebb lett volna egy
__CODE_END__, vagy bármi más, ami a funkcióra utal.Nekem ebből a teljes tervezetlenség és adhoc megvalósítás esik le, melyet máshol is látni a PHP kapcsán (például a különböző koncepciókra gondolok a függvények elnevezésénél - egybeírjuk, aláhúzással jelöljük, stb.).
Persze ettől még maga a funkció jó, csak ezután ne mondja senki se a Perlre, hogy olvashatatlan. :)
-boogie-
funkció == function
include_onceis függvényként jelenik meg például!funkció == feature
include_onceaz végrehajtásra is kerül, futásidőben hajtódik végre, részemről egyértelmű, hogy függvény. :) De látom úgyse tudlak meggyőzni... Valóban a PHP-s konstansok miatt nem feltétlenül jó a__CODE_END__jelölés, de a függvénnyel se vagyok kibékülve. ;)-boogie-
új jelölés meg minek?
__FILE__,__LINE__meg hasonlók. Most ilyen funkcionalitást ilyen néven nem lehet bevezetni, mert ez a konstansok szintakszisa. Új jelölést meg minek kitalálni erre, a C preprocesszor utasításainak kistestvéreit nem kell itt feltalálni szerintem... Lehetne kulcsszóval megoldani, de az kisbetűs a hagyományok szerint, és nem ütközik ki. A Perlben sem véletlenül__DATA__a jelölés... Mi marad? Függvények!perl gyökerek ;)
Szerintem a Perles megoldás miatt érzed ezt csúnyának. Szerintem ezzel semmi gond. Sokkal inkább az egyéb sok-sok nem teljesen átgondolt, illetve nem egységesen használt koncepció, ami PHP sajátja, sajnos.
Mai napig egy in_array() esetén fogalmam sincs, hogy a tömb van-e elöl.
(Bár ez már az én bajom ;))
Felhő
csatlakozom...
miért?
miért és mikor van/volna erre szükség?
bbalint
belinkeltem
nemtom. én ezt egy éve
exit();
--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu
nem jó!
exit()erre nem elég...:-)
Persze nem lehet benne a lezárás után "<?".
Elvileg ezt sem kell fordítani. Persze átnézi a fordító, de funkcionálisan megoldhatja a problémát...
--
Szeretettel: Károly György Tamás
kgyt&kgyt.hu - http://kgyt.hu