[robo47]

Ich habe seit einiger Zeit Probleme mit dem Parser der da standardmäßig wohl dabei ist, weil er PHP-Code als ParseError darstellt, obwohl dieser läuft, Beispiele:

Die auch jeweils im Quellcode rot unterstrichenen Teile habe ich Rot eingefärbt

Code aus dem PEL - PHP Exif Libary

return Pel::tra('Unknown');

Fehler:
Parser error "';' expected after 'return'." Bcms/trunk/library/pel/PelEntryShort.php

$p = ' ' . Pel::tra('(Photographer)');

Fehler:
Parser error "'{' expected after compound variable token '$'." Bcms/trunk/library/pel PelEntryAscii.php line 325

static function tra($str) {

Fehler:
Parser error "Function name expected after keyword 'function'." Bcms/trunk/library/pel Pel.php line 232


Irgendwie scheint das tra ein Problem darzustellen, warum genau verstehe ich nicht, weil der Code problemlos ausgeführt wird.

Code aus dem Zend-Framework

self::setInstance(new self::$_registryClassName());

Fehler:
Parser error "')' expected in function call (self)." Bcms/trunk/library/zf/Zend Registry.php line 54

Ist mehr ne Optische Sache, aber durchweg 15 Fehler im Punkt "Problems" stehen zu haben die anscheinend keine sind, nervt.

Es ist eigentlich auch die aktuellste Version von EasyEclipse (1.2.2 vom 12.2.2007 1330) über das Update gibt es nichts neueres.

[Ben]

Kann ich bestätigen!

[mepeisen]

Ich gehe jetzt mal vom PDT aus in der Hoffnung, dass easyEclipse das nutzt. Dort kann man unter window->preferences oder auch in den Projekt-Einstellungen einstellen, welchen Parser er nutzen soll. Unter Windows prinzipiell die richtige php.exe mit "-l" in der Kommandozeile, soweit ich das auswendig weiß. Ist denn dort was eingetragen und auch das richtige? Eventuell müsste man das aktuellste PHP lokal irgendwo hintun und die php.exe da raus nehmen.

Wenn ihr in einem Team zusammenarbeitet, empfehle ich nicht, den Pfad im Projekt selbst einzutragen, da es sonst blöd ist, die Sourcen zu teilen... Besser ist es, jeder trägt sich das unter Window->Preferences selbst ein.

Wenn der Parser nämlich nicht eingetragen ist oder ungültig ist, nimmt das Ding einen eingebauten Parser, der nicht unbedingt up-to-date ist.

Und noch ein Hinweis: Eclipse pflegt solche Infos je Workspace. Das bedeutet, dass ihr in einem neuen Workspace auch wieder neu nachschauen müsst.

[Ben]

Zitat von mepeisen

Ich gehe jetzt mal vom PDT aus in der Hoffnung, dass easyEclipse das nutzt.

Siehe hier.

Zitat von mepeisen

Wenn der Parser nämlich nicht eingetragen ist oder ungültig ist, nimmt das Ding einen eingebauten Parser, der nicht unbedingt up-to-date ist.

Das muss ich mal nachschauen.

[mepeisen]

Nachtrag: Den einen Fehler gibt übrigens auch mein Eclipse als Fehler aus im Zend-Framework. Komisch. Ich gucks mir auch mal an.

Noch ein Nachtrag: Fixed in CVS: https://sourceforge.net/tracker/?fun...group_id=57621

Ein weiterer Parse-Fehler im PHPUnit-Code:

PHP-Code:

interface PHPUnit_Framework_MockObject_Matcher_Invocation extends PHPUnit_Framework_SelfDescribing, PHPUnit_Framework_MockObject_Verifiable 


mag es nicht, da es keine mehrfachen Ableitungen erlaubt. Bei Klassen durchaus sinnvoll weils PHP ebenfalls nicht erlaubt, bei Interfaces jedoch ein falsch ausgewiesener Fehler.

Das ganze wundert mich nach wie vor, weil es ja den eingetragenen PHP-Parser nutzen müsste und nimmt man einen PHP3-Parser, wird so gut wie alles rot. Irgendwas ist da faul, ich suche mal weiter, wie man sowas abstellen kann...

[mepeisen]

Das ganze sind wohl wirklich Bugs in PHPEclipse. Und damit kommt wieder das alte Lied. Das Problem ist, dass denen wohl (soweit die Kommentare das im Forum mal hergaben) einige Entwickler in Richtung des Eclipse PDT- Projektes abgewandert sind oder sonstwie keine Zeit mehr haben. Daher auch der hohe Releasezyklus. Hilft in diesem Fall wohl nichts anderes als Warten.
Ich kann ansonsten nach wie vor nur das PDT empfehlen, in der aktuellsten Version ist es relativ stabil und die von PHPEclipse ausgewiesenen Parse-Fehler befindet es ebenfalls nicht als Parse-Fehler. Lediglich das direkte Ausführen von Skripten via Cli weigert er sich. Stattdessen arbeitet es wunderbar mit XDebug und der Zend-Debugger-DLL zusammen, sobald man mal gefunden hat, wo man die Ports einträgt
Die in PHPEclipse relativ komplizierte Debugger-Konfiguration ist da doch sehr einfach gehalten. Remote-Debugging braucht ja keiner