PHP Lint
Sziasztok, PHP-hez keresek JSLint-hez hasonló forráskód ellenőrző programot.
(a "php -i" meghívás jó, de ennél szigorúbb kellene nekem)
Ami nagyon kellene az a deprecated függvények előhozása. (Most váltottunk PHP 5.3-ra és meglepett a sok "elavult" függvény hívásaim)
Előre is köszönöm a válaszokat!
■ (a "php -i" meghívás jó, de ennél szigorúbb kellene nekem)
Ami nagyon kellene az a deprecated függvények előhozása. (Most váltottunk PHP 5.3-ra és meglepett a sok "elavult" függvény hívásaim)
Előre is köszönöm a válaszokat!
php -d error_reporting=-1 -d
ha van a fajlban barmilyen forditasi idoben eszlelheto hiba(error, deprecated, etc.), akkor ki fogja neked irni.
Tyrael
Re: php -d ....
Nekem nem egészen tiszta, hogy jelen esetben mi a fordítási idő, és mi a futási idő? Merthogy ha eregnemisletezik -re átnevezem az ereg függvényemet, akkor sem kapok hibát. Persze, ha futtatom a php fájlt, akkor megkapom az undefined function hibaüzenetet, de a php -l nem ad hibát.
arra valaszoltam, miszerint
forditas vs. futasi ido:
http://www.slideshare.net/sebastian_bergmann/php-compiler-internals
a lint onmagaban vizsgal egy fajlt, es csak szintaktikai ellenorzest vegez, ezert azt nem tudja kiszurni, hogy egy nem letezo fuggvenyre hivatkozol (hiszen lehet hogy a fajl amit vizsgalsz, az olyan helyen van include-olva, ahol definialt ez a fuggveny)
futas ideju ellenorzesre nem valo statikus kodanalizis, erre irjal inkabb teszteseteket.
Tyrael
Ezt nem teljesen értem: van
Megnéztem: hacsak nem memóriában rejtegeti, nem tárol lefordított kódot sehol a PHP. (konkrétan: strace-szel megnéztem, milyen file-okat nyitogat az apache, mikor megjelenít egy PHP lapot)
igy mukodnek az interpretalt
http://en.wikipedia.org/wiki/Interpreted_language
termeszetesen gyorsabb a vegrehajtas, ha nem kell eloallitani a bytecode-ot, ehhez lehet hasznalni opcode cachet (APC, xcache, Zend Optimizer, PHP accelerator, Zend Optimizer+, etc.), vagy befordithatod opcode-ba a kodot pl. bcompiler-rel.
Tyrael
Ezt értem, mi több, nem is
Csak a PHP esetében nem látom az értelmét, hogy miért kell ragaszkodni a forráskódként történő futtatáshoz, miért nem alapszolgáltatás, hogy befordítom, mint egy java programot és máris megspóroltam egy erőforrás igényes lépést, ami minden oldalletöltéskor végrehajtódik. Ha jól emlékszem, az általad felsorolt szoftverek nem részei a PHP-nek - a Zend optimizer meg mintha fizetős is lenne)
Hozhatnám példának a pythont, ami a libeket (időnként) .pyc file-ban tárolja és csak akkor fordít, ha úgy látja, a forrás változott a bytecode-hoz képest. Mibe került volna egy ilyen lépés a PHP fejlesztők részéről, már a kezdet-kezdetén? Ezen értetlenkedek. (vagy valami kimaradt a wiki-s link olvasásakor)
Ilyen a nyelv
Miért zavar téged, hogy fizetős a Zend Optimizer+? Java világban is van rengeteg fizetős csomag / alkalmazás.
Mindegyik opcode cache így működik, csak nem tárolja fájlban, hanem memóriában a fordított kódot.
Szerveroldali JS-t eddig hány
Egyébként nem az zavar, hogy fizetős bármelyik optimalizáló szoftver, hanem az, hogy mindez miért nem alap szolgáltatás a PHP-ben. Benne van a futtatóban, nem kerülne szinte semmibe a fejlesztőknek, hogy kiemeljék olyan szintre, hogy csak akkor elemezgessen/fordítson, amikor feltétlenül szükséges. A memóriába töltés egy bizonyos pontig OK lenne (strace alapján még ezt sem teszi meg), de nem feltétlenül áll rendelkezésre elég memória. Szóval nem értem, de nincs is nagy jelentősége. (egyébként sem akarok hosszú távon leragadni a PHP mellett, ez inkább csak egy mellékvágány: kicsit tanulgatom, amíg nem találok olyan szolgáltatót, ahol legalább java servleteket tudok futtatni, akkor visszamegyek a java-hoz, tomcathez)
Szerver oldali JS
Az APC pedig tervek szerint a PHP része lesz valamelyik elkövetkező változatban.
Bocs, kimaradt a "free"
Szóval ingyenes szolgáltatókra gondoltam.
Visszatérve a PHP témára: én ott akadtam el, hogy első perctől kezdve miért nem került bele ez a funkció a PHP-be? Mert az, hogy a 6-os (??? 5.4-es? kicsit kavarodnak a verziószámok :) ) talán, majd, egyszer bevezeti az már majdhogynem a halottnak a csók kategória szvsz.
Na mindegy, jelentősége nincs, csak picit bosszantó. :)
HipHop
(ha netán nem ismernéd akkor) a Facebook kiadott egy "csodát" (forráskód átalakított) HipHop néven. vess rá egy pillantást. (ha ennyire mániád a sebesség).
(egyszer talán a Zend-es fiúk is elmennek a sebesség irányába, előbb szedjék csak rendbe a nyelvet magát...)
Sebesség mániáról szó sincs.
Más téma, hogy magától a nyelv egy-két hülyeségétől is a falnak megyek (pl. a "következetes" névhasználat a beépített függvények esetében :D)
No mindegy, részemről lezártam a témát. :)
ui: facebook? Az mi? ;)
uíííí2: megtaláltam a github-on, ez a fb-s dolog valami egészen másról szól. (PHP -> C++ konverzió messze nem az, ami miatt "reklamáltam")
mintha szandekosan ertened
egyreszt solkprog ugy fogalmazott, hogy
tehat nem irta, hogy arrol szol, amit te szeretnel, masreszt viszont te azt irtad feljebb, hogy
erre a HipHop pontosan alkalmas, osszesen 1szer, az alkalmazas forditasakor parse-olja a fajlokat, utana osszerak belole egy darab binarist, ami inditaskor betolt mindent a memoriaban, aztan jonapot.
Tyrael
Persze, de hogy jött le
(a "mánia" nálam azt jelenti, hogy mindent félredobva, csak a sebesség és a sebesség... azért itt nem tartok)
Majd megnézem újra, de én csak addig jutottam, hogy ez a bigyó a PHP-ből generál egy C++ forrást, az eredménnyel meg csináljak, amit akarok. (ettől kezdve, tképp az apache modulból futó PHP programot CGI-vé konvertálva, ha nem tévedek)
De mindegy, mondom, hogy nincs jelentősége, csak bosszantott a dolog.
Persze, de hogy jött le
gondolom abbol, hogy interpretalt nyelvbe szeretnel defaultbol compile-olt mukodest.
ennel azert picit tobbet csinal
https://github.com/facebook/hiphop-php/wiki/running-hiphop
ok, akkor zarjuk itt le ezt a szalat.
Tyrael
gondolom abbol, hogy
Ezt valaki félreértette...
Épp itt volt szó róla, hogy a PHP is, mint általában az interpreterek, végez lexikális analízist és bytecode-ra fordítást. Én pusztán azt nehezményeztem, hogy ezt a két menetet miért nem lehetett kitenni egy külön progiba(is), a'la javac... Ott a program a PHP-ben, csak egy parancssori interface kellene hozzá. Gépikódú binárisra még nem vágytam. :)
No. Akkor thread closed. ;)
PHP hülyeségei
viszont:
A PHP "hülyeségeitől" én is néha falnak megyek (bár már megszoktam), de ennek valószínűleg történelmi okai vannak. A PHP még talán Perl-ként script gyűjteményként kezdte, majd lett C függvénykönnytár, és csak olyan PHP3-4 körül került a Zend alá. Ehhez még hozzájön hogy egy jó ideje nyílt a forráskódja, így (elvileg) bárki (főleg régen) hozzáfejleszthet bármilyen névadási sémával lefejlesztett függvényeket.
(a fentieket ne vegyétek készpénznek, mert rég olvastam utána, és lehet vannak benne pontatlanságok)
-Ezek a névadási anomáliák inkább problémája a PHP-nek mind az hogy néhány üzemeltető a nativ PHP megoldásnak a sebességével nem elégedett. (mert az utóbbira van kismillió megoldás). De egy alapértelmezett teljes körű UTF-8 használat se lenne rossz. (ami ha jól tudom akkor pont azért várat magára, mert nagyon belassítaná a PHP-ét..)
http://www.php.net/manual/en/
http://www.php.net/manual/phpfi2.php
a php-t (pontosabban akkor meg PHP/FI-t) Rasmus hozta letre 95ben, valoban eredetileg perl script gyujtemenykent indult, de ez meg azelott volt, hogy megnyitotta volna a kodot, addigra mar C-ben volt minden AFAIK.
ezutan ujrairta jott a PHP/FI version 2.0, ami egy komplett ujrairassal jart, majd Zeev es Andi ujrairta az egeszet, es Rasmussal egyeztetve ugy dontottek, hogy a kozosseg szetforgacsolasa helyett kozosen viszik tovabb ezt a verziot, es gyakorlatilag ebbol lett a PHP 3.
A PHP 4 az megint gyakorlatilag egy ujrairast jelentett, megszuletett a Zend Engine, ami a php azon resze, ami a php fajlok ertelmezeseert, vegrehajtasaert felelos, illetve a memoriaallokaciot vegzi:
http://www.slideshare.net/sebastian_bergmann/php-compiler-internals/3
A PHP 5 -ben debutalt a Zend Engine 2, es azota csak kisebb nagyobb foltozgatasok tortentek, a levlista alapjan most ugy tunik, hogy Andiek nem szeretnek, ha a tovabbiakban tul sokat valtozna maga a nyelv. :/
az inkonzisztens fuggvenyneveknek tenyleg tortenelmi okai vannak, es annyira nem nagy problema, mint amennyit az okozna, hogyha ezt kijavitanak es emiatt rengeteg kodot migralni kellene.
ettol fuggetlenul szerintem megerne meglepni valami major(php 6, ha lesz meg valaha) esetleg minor verziovaltas kapcsan (5.X)
a nativ unicode támogatás, illetve a PHP6 kudarcainak okairól érdemes megnézni Andrei slideját:
http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6
ha valaki nem tudná, akkor ő volt a unicode élharcos a php projecten belül, és a 6os verzió gyakorlatilag azért futott zátonyra, mert elakadt a unicodeosítás az érdeklődés hiányára való tekintettel és emiatt nem lehetett kiadni a 6os verziót, ami ugye frusztrálta a többi fejlesztőt is, ami miatt még kevesebbet dolgoztak a 6os ágon.
Tyrael
köszi a korrigálást
Ahogy észreveszem te elégé benne vagy a Zend-es berkekben. Így lenne két kérdésem, (ha véletlenül olyat kérdeznék amit a linket oldalakon le van írva akkor sorry)
-Legújabb info PHP 6-os verzióról? Annyi mindent lehetett az évek során olvasni róla, hogy engem teljesen összezavart. A legújabb info mi? Körülbelül mikorra ígérik, és körülbelül milyen tartalommal?
-inkonzisztens függvénynevek átírása azért távlati célként kivan tűzve? (sőt én azt se bánnám ha kidobálnák a beépített függvényeket a nyelvből, és mindenre megírnák az osztály/objektum alternatívát... ami azért szép lassan folyamatban van... Jól érzem én ezt kívülről hogy ilyen irányba akarnak elmenni?)
PHP6 nem haladt a fejlesztés,
nem haladt a fejlesztés, nagyon messze voltak még mindíg a kiadható stádiumtól (elsősorban a beígért unicode miatt akadtak el, az nem haladt, viszont anélkül nem lehetett kiadni mert annyira be lett harangozva), amit lehetett visszaportoltak az 5-ös ágba, ebből lett az 5.3-as kiadás, illetve néhány dolog a (ha minden igaz hétfőn alfa verzióval megjelenő) 5.4-es verzióban lesz elérhető.
tehát gyakorlatilag a fejlesztés most ott tart, ami újdonság az 5.4-es verzióban megjelenik, array dereferrencing, traits, illetve végre el lesz távolítva egy csomó legacy cucc, mint register_globals, safe_mode, etc.
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/NEWS?view=markup
hogy mi lesz a következő verzió az 5.4 után, azt még nem tudni. a végtelenségig nem lehet major verziókat léptetni, viszont előbb utóbb el kell dönteni, hogy kijöjjenek egy olyan 6os verzióval, ami már nem azokat a feature-öket tartalmazza, amit anno beígértek, vagy esetleg egyszerűen átlépik ezt a verziót és nem lesz 6os sosem.
igazából többször felmerült az internals levlistán, de nem sok támogatója van a core fejlesztők közül az ötletnek, inkább a php-ban fejlesztő olvasók szokták néha panaszolni.
nem szerepel ennek a megoldása semmilyen todo listán, szóval nem számítanék rá nagyon. :(
Tyrael
köszi
PHP 6-ot sajnálom:(
anno PHP 5.3 kiadási közleménye után illetve most PHP 5.4 listájának olvasása közben végre megint kezdem érezni hogy fejlődik a PHP. Még ha különösebb távlati célok és irány nélkül.
Teljeskörű UTF-8?
Ha csak ennyi, akkor nem csodálom, hogy a fejlesztők nem törik magukat érte.
------
stringek
$árvíztűrő_tükörfúrógép=123;
ha kíváncsi vagy a részletekre (szerintem nem vagy, mert akkor nem flegmáznál, hanem megnézted volna a linkeket, amiket adtam), akkor itt le van írva, hogy mi volt az eredeti terv, és ez mit jelentett volna pontosan a userland szempontjából:
Tyrael
Tény: annyira nem érdekel a
De korábban is írtam: számomra a PHP eleve egy kényszerpálya, nem akarok túl sok energiát belefektetni.
Beszélgetni meg szeretek, ha van kivel, miről. Ha mindenki tartaná magát ahhoz, hogy a kérdéseinek, problémáinak utánajár, akkor kb. kihalna az összes fórum.
Írom ezt úgy, hogy más fórumokon játszottam egy darabig: valaki feldobott egy kérdést, én meg google-n megkerestem a választ. Az esetek 98%-ban gond nélkül megtaláltam a megoldást.
nem fizetős
Letöltés -> jobb felső
Next Steps
* Download Free Trial
Nekem ebből az jött le, hogy fizetős, ezért írtam.
Az a baj, hogy elbeszélünk
Tehát, amit írni akartam, az az, hogy a "<?php ereg(); ?>" tartalmú fájlt gond nélkül elfogadja a php -l akármilyen hibajelzéssel látom el. Erre írtam, hogy nem tudom, hogy a fordítási idő mit jelent, de ne is menjünk bele!
A kérdésem inkább az, hogy egy "jól bekonfigurált" rendszernél itt hibát kellene, hogy dobjon, vagy csak és kizárólag szintaxist vizsgál a rendszer, és az elavult utasításokat nem fogom tudni ÍGY megkapni?
igen, a fuggvenyhivasok csak
itt megtekintheted az 5.3-ban deprecated-de tett fuggvenyek listajat.
Tyrael
Is there a static code
PHPMD
PHP_CodeSniffer pear csomag
Re: PHP_CodeSniffer
(a többiek ajánlatát is köszönöm, sajnos csak szabadidőben tudok ezekkel foglalkozni, így lassan haladok, de majd nézegetem sorba azokat is!)
http://www.icosaedro.it/phpli
Itt találtam egy PHPlint nevű bigyót...